At 20:55 25.02.00 -0500, you wrote:
Stefan Matthias Aust sma@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.