Juan Vuletich <jvuletich at dc.uba.ar> writes:
> To me eToys what you can find in the eToys package. That's why I put
> it there!
> 
> Going thru Lex's list. (Lex, I didn't answer to your post because I
> think the list should be built by the community, and I didn't want to
> sound authoritative on this!)
> - Tile based programming system. Yes. The central part of eToys.
> - Halos. No. Halos are key to Morphic.
> - Named morph search. No. I'd put this in 'MorphicExtras'.
> - Uniclasses. Yes. They were implemented in Squeak to support
> eToys. And they are not Smalltalky to me. However, 'make own subclass'
> is not eTtoys, and distinct from uniclasses to me.
> - SmartRefStream and ImageSegments. No! Why would they?
> - Projects and saving projects. No.
> - Paint tool. No.
> - Flaps. No.

You propose to keep almost everything that makes Morphic complicated.
Basically, you propose removing the tile-based programming; I'll
ignore the uniclasses proposal for now because it is a small amount of
code.

I wonder how much impact tile-based programming really has on Morphic,
and in particular on class Morph?  My gut instinct is (a) a little
bit, and (b) that we can do this little bit without making a
non-reversable change.

There is an argument that every little bit of simplification can help.
But I do not find it such an amount of simplification to be worth
cutting off part of the community with such finality.  I'd rather have
the extra mess, if it meant the Squeakland guys were still associated
with squeak.org.

Further, I see nothing that is so hard about making the tile-based
programming unloadable and reloadable.  It is just like any other
partitioning project.  Make a tile-based-programming project on
Squeaksource, start recategorizing methods and classes, and go from
there.  If someone cannot do this much, can they really do a major
Morphic cleanup?


-Lex