om

While I'm waiting for the unix port to stabalize again so I can resume
my attempt to make it run on the framebuffer [I don't have the skills to
repair the broken VM sources cuz I don't know how the partially
implemented new design is supposed to work..] only I was messing with a
CPU emulator to experament with some of my craziest ideas.

In doing so I ran into what seems to be a correctable limitation of the
current morph assembly system...

om

Viewer, while stunningly slick, is not a very practical tool (in my
experience at least...) While it can be used to animate morphs on the
screen it can't be used to visually construct user interfaces...

Viewer excells at pushing polygons around the display but I have not
found a way to use it to generate _CLASSES_. 

Since I'm too lame to figure out how to generate layouts with the
existing tools... (And judging how varrious things that shouldn't be
resizable in Browser are, it appears that everybody just gets it
GoodEnuff and leaves it that way...) 

The idea is to put an item somewhere in one of the halos, "enable
authoring mode".

So when you grab a rectangle out of the parts bin, and enable this
setting, it will open a browser and prompt you to enter a new class name
(with appropriate safety precautions.) 

When you take another rectangle out of the bin and drop it into the
first, it will _AUTOMATICLY_ add whatever code it takes to put that
rectangle there whenever the class is started... In this fassion _ALL_
possible layout options should be recorded... If you set the corners to
rounded, the authoring mode should add this to the new class... (A good
example from the immage is SameGame morph which, by default, loads with
square corners but the instance in the image has round corners. --
Apparently it is too much of a bother to update the class...) 

The generated code should add to the new class all code necessary to
communicate with the embedded morph and instead of having to hunt down
the methods for handling events, there should be an option to check off
the events you want to handle and the method-stubs should be added to
the appropriate classes automaticly. ;) 

This approach might have some limitations in cases where you _WANT_ a
behavior to change dynamicly but in general this approach _SHOULD_ work
fairly well for the majority of cases...

In general, its really cool that Squeak can have "mutant instances" but
it won't really be useful unless it can be used to mutate classes as
well. 

Am I cool enough to implement this myself? Not yet... =( 

The text above should be more than proof that I am hopelessly lazy. ;) 

-- 
Having never read a manual, it takes less effort to hack something
togeather with www.squeak.org than it does with C++ and five books.
http://users.rcn.com/alangrimes/