On Friday 27 September 2002 07:30 am, Aaron J Reichow wrote:
> But surely, Morphic has to have issues.  Speed is the biggest one
> I've heard and observed myself.  What else is wrong with Morphic
> and how can we fix it?  I'd say we have one of the coolest UI
> toolkits around, but it can
>
> 1. Speed
>    * Solution: ?

Which speed? There are things that are done inefficiently in some 
Morphs (witness the recent CSs improving big ListMorphs); there's 
also the speed of the underlying framework.

> 2. No a consistent and comprehensive 'regular' set of widgets for
> Morphic. * Solution: Commuinity could decide on Prefab, BobsUI or
> something new- but a partial consensus would be good, so newbies
> (or oldies) know where to put work when they want a new widget part
> of this consistent set

Agreed. One of the popular FAQ's has to do with "how can I make a 
simple, traditional GUI?".

> 3. I'm told events in Morphic suck?

Which events? There's a few layers:

* Getting the VM events into a queue and processing them. Getting the 
events is done by a separate process and is not a major speed hit. 
Processing them is done by the Hand (in processEvents), and there's 
lots of work being done there (most of which has to do with finding a 
morph to handle each event). However, it's being done at user event 
speeds.

* Finding a handler for mouse/keyboard events. The default routing of 
these is very general purpose, with the entire morph structure below 
the mouse being passed the events in many cases. I suspect there's 
some room for improvement here.

* Hooking EventHandlers to user code. This is pretty efficient, but is 
inflexible with the current EventHandler architecture (i.e. you'd 
have to come up with a different EventHandler if you added different 
kinds of UserEvents).

* Update notification between Morphs (especially parent/child). There 
are two kinds of notification:

* Morph>>changed (which invalidates a rectangle and eventually causes 
a redraw). We may be able to cut down on the amount of invalidation 
and drawing that's being done (Andreas has some thoughts on this, I 
believe).

*  the MVC model notifications for events like list selection changed, 
etc. The MVC notifications can be inefficient when a model has many 
dependents that aren't interested in all the different events. The 
new event code should improve this situation, but I don't know how 
much of an issue it is outside of (say) the Browsers.

I'd also add:

4. (apparent) complexity. The Morph interface is big, and it's hard to 
tell at first glance what is important, what should be overridden in 
subclasses, what's pluggable, etc. This may be a documentation 
problem, and it's possible that tools can help (like Browsers that 
know to restrict visibility to different categories of methods, and 
Morph builder wizards).

-- 
Ned Konz
http://bike-nomad.com
GPG key ID: BEEA7EFE