On Monday 30 August 2004 8:34 am, Avi Bryant wrote:
> It would be nice to see some kind of proof of concept of a
> Morphic-without-windows, even a very rough one...

If you think about what windows do for us, you'll see that there have to be 
other ways to do what they do.

What overlapping windows do (off the top of my head):

* they provide single grabbable object that acts as a container and may be 
moved or overlapped with others to save pixels and limit what you have to 
look at at any instant

* they bundle several related UI elements together and often let you resize 
the areas that those elements occupy

This isn't really very much.

We've seen many environments that don't use overlapping windows at all, 
ranging from the very task specific (CAD programs, etc.) to different user 
interface models (like the visual languages) to all-text environments like 
some versions of Emacs.

If the problem is just being able to re-use pixels and organize what you see 
at any instant, then all we need is some facile way to remember the various 
arrangements of things that we've constructed, rearranged, or had 
pre-constructed.

Instead of having to stick things in windows (or other containers), if there 
was a more general way to specify the arrangement constraints of UI elements 
(along with wiring up the events, etc.) then that could be used both to glue 
UI elements together into tools and to glue those tools into task-oriented 
snapshots of a workbench or desktop configuration. Windows themselves aren't 
needed for this purpose, though it is nice to have common UI elements for 
resizing and grabbing.

The ownership relationship in Morphic is an example of a global policy for 
such constraints that mostly seems to work well but can be limiting 
sometimes. I just added the ability for Connectors to attach to submorphs; 
this introduced the necessity to add new accessors to EToys so that the 
embedded pins and their owners could talk with each other.

-- 
Ned Konz
http://bike-nomad.com/squeak/