MVC vs. Morphic (was Re: Shrinking)
Ned Konz
ned at squeakland.org
Mon Aug 30 17:44:20 UTC 2004
On Monday 30 August 2004 8:34 am, Avi Bryant wrote:
> On Aug 30, 2004, at 4:02 PM, Ned Konz wrote:
> > On Monday 30 August 2004 4:43 am, Pavel Krivanek wrote:
> >> IMHO developers are frustrated by Morphic. It's very modern and
> >> interesting
> >> GUI framework, but it didn't come up to all expectations.
> >
> > I think they would understand it better if it didn't have the windows.
>
> That's a very interesting statement. How do you imagine this working?
> Do you mean getting rid of all the UI that currently uses SystemWindow
> (Browsers, Debuggers, etc), replacing them with Self-style outliners?
> Or do you just mean making SystemWindows be morphs like any others and
> getting rid of all the special cases around them?
I meant that as soon as developers see things that look like windows (and
menus, I suppose):
- they have certain expectations as to how they should act and feel, which is
not unreasonable since they look familiar.
- they associate their previous concepts of "window", "widget", "event loop",
etc. with the Morphic artifacts that appear to correspond to those concepts.
- they then get frustrated when they run into differences between how these
familiar user interface elements act (and look) in Squeak and how they act
and look in the operating system with which they're most familiar.
- they also miss the design philosophy which doesn't differentiate between
submorphs of the World and submorphs of those morphs. There is no distinction
in Morphic between a "widget" and a "top level Morph".
I'm not saying that the tools that we have in Morphic that happen to live in
windows aren't useful. It's just that there's this disconnect between things
that want to be their own mini-worlds with an idea of focus and locality
(i.e. windows and their embedded morphs) and things that don't.
I'm also not arguing that Morphic has the best solutions to the problems of
event routing, layout, drawing, etc.. As someone who has done a fair amount
of Morphic programming, I feel strongly that we can make Morphic better than
it is now. However, I'm not sure that a wholesale refactoring of Morphic
would be worth the time at this point, as there are a couple of important new
UI systems in the works (Tweak and Croquet), and I also think that the desire
for a cleaner, more "standard" user interface that includes the elements that
people are used to is not necessarily best met by Morphic.
As you know, there's lots of stuff in Morphic (and Squeak in general) that is
a result of its focus on being the platform for EToys. I think that much of
the current complexity of Morphic is due to design decisions (made under time
pressure, of course) from EToys (and Alan's various demos) creeping into what
started out as a much simpler system.
For example, looking at different historical versions we see:
v 1.31 (before EToys):
Morph selectors size 231
Morph withAllSubclasses size 101
v 2.0 (the dawn of EToys):
Morph selectors size 347
Morph withAllSubclasses size 129
v 2.1
Morph selectors size 357
Morph withAllSubclasses size 138
v 2.8
Morph selectors size 540
Morph withAllSubclasses size 269
v 3.0
Morph selectors size 924
Morph withAllSubclasses size 343
v 3.6 full
Morph selectors size 1090
Morph withAllSubclasses size 394
the Squeakland developer's image that I'm working on right now, with m17n and
Connectors in it:
Morph selectors size 1258
Morph withAllSubclasses size 444
An example of this effect is that there are two different and conflicting
idioms (well, three if you count my work in Connectors) for associating
behavior with UI events:
* You can override #mouseDown:, etc. to get the behavior you want
* You can plug the EventHandler by using #on:send:to: (I think that this may
have been added for triggering EToys scripts from UI events)
* You can override #processEvent:using: for more control over how things are
handled (I do this in my QHSMMorph which is the basis for my new Connectors)
And there's also one-off variations on this, like (some of the) buttons that
give you a different way to plug the behavior.
> It would be nice to see some kind of proof of concept of a
> Morphic-without-windows, even a very rough one...
We have one. It's called EToys.
I use Morphic all the time with Connectors and its various morphs and menus
without ever having to see windows.
--
Ned Konz
http://bike-nomad.com/squeak/
More information about the Squeak-dev
mailing list
|