MVC vs. Morphic (was Re: Shrinking)
Ned Konz
ned at squeakland.org
Mon Aug 30 14:02:56 UTC 2004
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.
> Firstly it doesn't look conventional, it doesn't contain implicitly
> standard GUI components like combo-boxes etc.
Is there anything in Morphic that would keep you from building one easily?
> Without mouse support you can
> do absolutely nothing.
What mouse support is missing?
> It has strange windows management.
The windows in Morphic are not really the primary objects like they are in
most UI systems. As far as I can tell, they were made so that the existing
tools in the MVC environment could be ported quickly to Morphic. That's the
origin of all the Pluggable* components; you will see that there are pairs of
them with similar APIs for MVC and Morphic.
> Inactive windows disable all its components (look at Zurgle to see it).
Zurgle has, as I recall, its own idea of focus and window activity.
> You can't switch
> between submorphs using Tab key etc.
We have had this working from time to time.
> One of the most strange features of Morphic and MVC is the single world
> cycle. One long computation can make whole GUI unusable.
How is this different from what was done in Mac OS 7 or Windows 3.1? I recall
many applications that would make the whole GUI unusable by doing just what
you describe in response to a UI action.
Later operating systems tended to assign a separate thread per application;
they could easily maintain the behavior of the rest of the system by using
message queues.
In fact, if you look at Squeak as a single application (which it is, despite
the windows) ours is a fairly typical architecture. Events come up from the
VM and are dispatched in a single loop.
There is enough shared state in Squeak that having multiple GUI processes
would require quite a bit of work for little benefit if you wanted anything
more interesting than a "windowing system". I want to have live objects in my
world, and I don't particularly want them confined exclusively to windows. As
soon as morphs need to talk to each other (which is not generally the case
with windows but is essential for pretty much everything else we do with
Morphic) you wouldn't be able to call the methods of other morphs directly
any more, which would require a number of changes. You'd probably have to
distinguish between top-level morphs and other morphs; the top-level ones
would have their own message queue, etc. But then there would be a difference
between (say) a RectangleMorph loose in the World and one that was embedded
in a window or other top-level container: the one in the window could have
its methods called directly and would be a "second class citizen" intended
only for embedding, and the one loose in the World would not be able to have
its methods called directly. This would be like the distinction between
"widgets" and "windows" in many windowing systems.
I agree that mixing models has led to strangeness; the attempts to make the
SystemWindows behave more and more like operating-system windows despite
their existence alongside other non-window morphs have not always resulted in
consistent behavior. But at least it got the MVC tools working in Morphic.
One example of this strangeness is the "topmost window" concept which is
completely at odds with the existing Morphic layering; another is the concept
of "window focus". Morphic itself doesn't have focus other than the halos,
but the concept was added to the windows. So if you have a mixture of windows
and non-windows in the world, you will sometimes see situations where the
Z-ordering will suddenly be reorganized (for instance, after you enter a new
project or save the image).
As it is now, it's quite simple to put long-running computations in background
threads; you just don't let the background threads call methods directly on
Morphs. We have addDeferredUIMessage: to queue up action from the background
threads for later execution in the UI thread during the next window cycle.
> It's not a feature
> of Squeak's process scheduler. I have created an experimental window
> manager with separated message passing cycles, all GUI messages were sent
> through shared queues and it has worked perfectly.
But Squeak isn't a window manager (despite the things that look somewhat like
UI windows), and the things in the World (windows or other morphs) aren't
separate applications. Or, looked at another way, every morph is a separate
application whether or not it is a top-level morph (they each have their own
step methods), but then there is still no distinction between top-level
morphs (well, other than the World itself) and embedded morphs. Top-level
morphs are just submorphs of the World, and a lowly StringMorph or
RectangleMorph deep in a construction somewhere inside a window is no less
live than the window itself.
If you wanted to make a UI in the style you describe -- merely concerned with
standard kinds of windows and UI elements inside them -- many of the issues
around intra-Morph communication would not be a problem. But you're missing
the point, I think; Morphic was not intended (as far as I know) as a
windowing system. As you point out, the MVC system is much closer to this
model, with its controllers that are associated with things that look like
windows on the desktop.
Whether Morphic is the right design for the kinds of things *you* want to
build, I don't know. Maybe it isn't a good fit.
However, there is nothing that I can think of in Squeak that would prevent you
from writing a completely different UI system fairly easily. In fact, there
have been several of these already: the Parks PDA that John Maloney did had
one, his Scratch system has another, Andreas' Tweak system has another,
Croquet has another, and so on.
The co-existence of MVC and Morphic shows that it is possible to make a
completely different UI model and still re-use the basic UI system (events,
canvases, invalidation, etc.). We could probably make the work required to
add different kinds of Projects/Worlds a bit easier, though; there's a fair
amount of code at the project level that assumes that projects are either MVC
or Morphic.
--
Ned Konz
http://bike-nomad.com/squeak/
More information about the Squeak-dev
mailing list
|