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