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
- 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.
- 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?".
- 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).