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.