At 20:55 25.02.00 -0500, you wrote:
>Stefan Matthias Aust <sma at 3plus4.de> wrote:
>> 
>> The new UI framework should be small, fast, easy to understand, simple to
>> extend and still powerful.

>Morphic is actually pretty straightforward.  Morphs have submorphs. 
>Morphs respond to events.  Morphs have a color.  Morphs have a
>rectangular bounds.  The top-level morph is called a world.  Etc.  This
>stuff is very easy to understand, except of course that it isn't
>documented anywhere.  :)

I was more refering to the fact that alone the class Morph has more than
500 !!! methods.  How does players and morphs interact.  Did you ever tried
to understand how the HandMorph (229 methods!) works and interacts with
other morphhs?  Did you notice that (probably because of lacing
documentation) people solve common problems like sizing submorphs of a
resized morph in at least four different ways?

You're right, you can figure out the basics yourself but the problems start
with all the details.  For example, I'm pretty sure that the balloon help
stufff is still too complex.  Did anybody noticed that you cannot have one
help per hand as it IMHO should?

>As for small frameworks, Morphic isn't, but the one you describe doesn't
>seem exactly "small", either.  Graphic frameworks seem to have a
>fundamental complexity about them.

I still think that you can do things a little bit simpler than in morphic
and still get the the same or similar effect.  Morphic is great to learn from.

>As for speed....  The *big* slowdowns I've seen, though, are *not*
>because of the framework, but because of particular widgit
>implementations:

I once talked with Andreas about this and I think he thought its mainly the
way the handmorph(s) work that slows down the system.  But of course your
observations are also valid.

>For example, Stefan proposes that not all Morphs should be
>able to have sub-morphs.  Is this a good idea?  bad?

Well, as you probably assume, I think its a good idea because there're a
few but common classes which are end nodes in the Morph hierarchy.  

Let's take a StringMorphs as part of a ListMorph as an example.  It doesn't
need all the logic for supporting submorphs.  It's not only the space taken
by the submorphs instance variable but also the code in calculating the
bounds which has to take in account that submorphs may be outside the
morphs bounding box.

Let's also look at Morphs like system windows or buttons.  They look like
they could use the general submorph framework.  But try what happens if you
add more submorphs to a button. It doesn't work.  It knows that it has
exactly one submorph.  For windows, the subpanes (aka submorphs) are stored
also explicitly so you don't mix them up with the rectangle morphs for the
title bar.  Here I think, morphs without the general framework but with
code for their specific needs is better.

If you want to add more than a morph to a button, use a Panel or Box morph
which would make one composite morph out of simple morphs.


bye
--
Stefan Matthias Aust  //  Bevor wir fallen, fallen wir lieber auf.