A problem hindering SmallTalk's popularity:

Richard A. O'Keefe ok at cs.otago.ac.nz
Wed Jul 31 02:12:19 UTC 2002


The radio button problem turns out to be a very educational one.
Squeak has many of the traditional GUI widgets:  lots of different
kinds of buttons, lots of different kinds of menus, lots of different
kinds of lists, lots of different kinds of text areas.  This makes
them not so good as educational examples, because you just use them.
The fun of radio buttons is building them.

Poking around a bit more with Morphic, I've started to wonder whether
the rather large size of Morph might actually be _justified_, because
there seems to be a highly relevant slogan:

    ANY MORPH CAN...

Let's consider the abstract needs of a radio button group.
 * "container"
    - holds buttons so they can be moved as a group
 * "button" 1..n
    - has visibly different ON and OFF states
    - tells the co-ordinator when it is pressed
 * "co-ordinator"
    - holds the state (1..n)
    - tells buttons when to turn ON and OFF

Now,
    ANY MORPH CAN...    be a container.  Just use addMorph{,Back}: or
    addAllMorphs: to add submorphs.

    ANY MORPH CAN...    be a button.  The visibly different states could
    be colours (easy as easy) or borders (plain/raised/bevelled/thick/thin)
    or even costumes.  More to the point, whatever kind of Morph we choose
    for our buttons, the co-ordinator can tell the (i)th button:

	button on: #MouseDown send: #state:event:morph: to: self
	    withValue: i

    and then when you click on the button, it will send
	coordinator state: (i) event: (mouseDownEvent) morph: (thisButton)
    and the coordinator will know what to do.

We could say there's another Morphic slogan:

    YOU DON'T HAVE TO INHERIT TO BE RICH.

After discovering on:send:to:withValue: last night, it took me another half
hour to put together a three-class solution.
    RadioGroup, a new subclass of Object, acting as co-ordinator.
    EllipseMorph, the existing ellipse morph class, with no changes.
        I used the default yellow colour for off, red for on.
    AlignmentMorph, the existing alignment morph class, with no changes,
        as container.
Unlike my previous example, this one could handle any number of buttons
up to an arbitrary limit of 20, and could present them in a vertical or
horizontal row.

The only real weakness in this new version is that it doesn't handle
labels; I tried stuffing a StringMorph in one of the EllipseMorphs and the
alignment went crazy.  I have no idea why.

Doing it again, I might make RadioGroup a subclass of AlignmentMorph.

The thing I particularly like about this solution is that there isn't the
slightest need for the various buttons to be the same shape.  If you want
to select between various nibs for a pen, for example, the morphs used as
buttons can be images of the nib.

Then there are the Squeaky things you can do like indicate the active button
by animating it, perhaps having it jog up and down gently, or rocking; and
you can make the buttons make noises when they are pressed for audio feedback.

If anyone has suitable animal pictures and sounds, a neat Morphic tutorial
would be an "AnimalChooser" that put up a radio-button-group-like list of
animal pictures, letting you choose any one, and making the appropriate sounds.




More information about the Squeak-dev mailing list