Bad Aspects of Morphic?
Ned Konz
ned at bike-nomad.com
Fri Sep 27 15:11:57 UTC 2002
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
More information about the Squeak-dev
mailing list
|