Hello!
Anyone with experience programming more average or normal GUI toolkits knows that Morphic is different. I think that most people, if they learn how to use it, find Morphic better in many ways. At least I do. I find myself wanting to change my environment, be it Mac OS X, Linux or Win98 (only at work, and not for long! :), but then I realize that Cocoa/GTK+/Win98 are a PIA compared to Morphic for a lot of things.
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: ? 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 3. I'm told events in Morphic suck?
Regards, Aaron
Aaron Reichow :: UMD ACM Pres :: http://www.d.umn.edu/~reic0024/ "the profit system follows the path of least resistance and following the path of least resistance is what makes a river crooked." :: u. utah phillips
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).
On Fri, 27 Sep 2002, Ned Konz wrote:
- 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.
Both I suppose, but I was specifically speaking of the underlying framework. There are point-specific problems (and related speedups) like we've seen on the list lately, and those certainly are needed as well. On an iPAQ, for instance, a great many actions are slower than seems natural- when I click on a button, there is a pause before the button realizes it's been tapped, usually shown to the user by the fact that it changes its color; opening any menu takes a bit of time; opening even a simple (Workspace) window takes a couple seconds and so on.
The bottom line is, to a user, Morphic can *feel* mighty slow. This is dependent on hardware of course. On my iBook 500 or my Windoze Celery 400 MHz at work, Squeak mostly fast enough as a user and development environment. Faster than OS X, for me. But on something slower, like a 206 MHz StrongARM, it's quite sluggish. I'm not sure what the percentages are, but a lot of people have hardware faster than this (equivalent to a 133 MHz P5?), but it would still be beneficial to have a fast Morphic. We developers almost always have faster machines, so it's no a priority- but it's still an issue.
Don't get me wrong, I'm not complaining, but I'm interested in an enumeration of what's not quite great about Morphic.
Agreed. One of the popular FAQ's has to do with "how can I make a simple, traditional GUI?".
I personally really like Prefab. I asked if others used it a while back, and there wasn't much in the way of responses. For those who want to create "average" apps now, it looks as if it were the best thing going. But because there are a few other options, and developers are spread between them, Prefab and the others will most likely not end up to be really great toolkits.
Scott Jaederholm is out of computer range now, but he narrated his journey whilst creating a *commercial* app with Dynapad using the included Prefab. He started doing it using the regular morphs, but was seriously -wowed- when he discovered Prefab, and it sped up his development time quite a bit. So few people even know about Prefab, but it is a good tool.
Which events? There's a few layers:
As I said, this I'm just told. In the applications and tools I've created so far, I've not had a problem with Morphic's events, other than that what is meant is a little unclear sometimes. Brian Rice may be able to speak about what he sees wrong about Morphic's event system.
- (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).
I agree. I think deciding on which "normal" widget set to endorse would help as well- that way, when a newbie asks "How to I make a GUI app?" you can point her to a document on making such an app with Prefab or whatever. Once one gets the hang of Smalltalk, Morphic's lack of documentation isn't as bad, IMHO. I'm sure there are those that disagree with that statement. Morphic was a big PIA at first, because I had no idea what was going on, and with so very few docs at which to look. I didn't even know what kinds of questions to ask the list. But as I figured out the basics, it all "bloomed" and made sense, mostly.
In some ways, I think this style of learning imparts the student with a lot more working and general knowledge than being told how to do it. I am glad I learned Morphic and Smalltalk "the hard way." After all, the system is nothing but objects, one just have to figure out how to plug them into eachother. Of course, not everyone learns in the same way, and many simply don't have the time to spend hours just poking around in a Browser without being productive.
Regards, Aaron
Aaron Reichow :: UMD ACM Pres :: http://www.d.umn.edu/~reic0024/ "civilization is a limitless multiplication of unnecessary necessities." :: mark twain
One current problem involves the ScrollPane [ScrollPane+TwoWayScrollPane]: The entire contents of scrollpanes are drawn all the time, even when most of them are not visible. A heavy user of ScrollPanes can get burned bad on this. Lex Spoon has a patch that fixes this is the special case of PluggableLists, but it is still a problem for others. I made the suggestion that perhaps Layouts can be used to help determine visibility and avoid excessive drawing of invisible morphs; maybe there are other approaches to this too [cache the order, like a bsp maybe?].
So far, I can't say that there is anything slow about the Morphic framework itself; all the slowness I have seen so far is the fault of individual morphs that are especially bad about occluded drawing (like PluggableLists, above, and the multiple selection lists, which I posted a fix for earlier). Ironically, Morphic's speed has let things like this accumulate without anyone noticing much (for a while).
Eddie
----- Original Message ----- From: "Aaron J Reichow" reic0024@d.umn.edu To: "squeak list" squeak-dev@lists.squeakfoundation.org Sent: Friday, September 27, 2002 10:30 AM Subject: Bad Aspects of Morphic?
Hello!
Anyone with experience programming more average or normal GUI toolkits knows that Morphic is different. I think that most people, if they learn how to use it, find Morphic better in many ways. At least I do. I find myself wanting to change my environment, be it Mac OS X, Linux or Win98 (only at work, and not for long! :), but then I realize that Cocoa/GTK+/Win98 are a PIA compared to Morphic for a lot of things.
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: ?
- 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 3. I'm told events in Morphic suck?
Regards, Aaron
Aaron Reichow :: UMD ACM Pres :: http://www.d.umn.edu/~reic0024/ "the profit system follows the path of least resistance and following the
path
of least resistance is what makes a river crooked." :: u. utah
phillips
"Eddie Cottongim" cottonsqueak@earthlink.net wrote:
One current problem involves the ScrollPane [ScrollPane+TwoWayScrollPane]: The entire contents of scrollpanes are drawn all the time, even when most of them are not visible. A heavy user of ScrollPanes can get burned bad on this. Lex Spoon has a patch that fixes this is the special case of PluggableLists, but it is still a problem for others.
Hmm, I suppose the fullDrawOn: method, or maybe one of its close cousins, might be a good place to insert the smarts. Let's see, drawSubmorphsOn: looks promissing -- TransformMorph already has this method overriden to do some clipping, but it simply isn't restrictive about which morphs get drawn.
-Lex
squeak-dev@lists.squeakfoundation.org
-
Aaron J Reichow -
Eddie Cottongim -
Lex Spoon -
Ned Konz