On 11/15/06, Aaron Reichow <revaaron at bitquabit.com> wrote:
> I didn't do that by calling a #font: method on the TaskbarClockMorph,
> but I didn't see any need to implement such a thing.  Maybe that is
> the kind of abstraction missing in Morphic according to some folks.
> Rather, I just went to the TaskbarClockMorph instance, asked for the
> text submorph and set its font.  Unlike other widget sets, the new
> morphs I build are composed of other morphs, and it's easy to access
> those submorphs and do what I want to them. My experience on some
> other platforms is just the opposite- I am stuck with what the
> developer thought important enough to put it in the new widget's
> API.  If she thought that I woujldn't need to change the font, I was
> stuck.
>
I would have implemented that font: method, because it abstracts
away the details of the internal structure of the clock morph, and
this tends to pay off in the long run. I also agree that Morphic is
flexible and easy to work with. I usually have a model and use an
observer-type of pattern to update the morphs. When I first saw
Morphic, I was very suspicious of the lack of a model - morphs
seemed to be all UI-objects! Then I realized that this is sometimes
simple and useful, and that it is easy to do your own morph-model
architecture.

Best regards, Micke