Chris,

You're overly excited. Please calm down, you're scaring me.

>It may also be desirable to have i-vars to hold onto a bottom status
> bar, collections of top/bottom/left/right flap panes, tear off tool bars,
> etc.

Here's what currently wrong. I have a list of all the morphs that belong to
the frame, kept in a lists called submorphs. I also have the capability of
naming each of these morphs. Over the years, we've ignored that list and put
another pointer to particular morphs in ivars. The ivars aren't very happy
creatures in a dynamic environment, as they tend to fix the structure of the
description instance. Our morph friends don't like this kind of structure
(or at least mine tend to be free range morphs ;-)

I'll give you an example. Currently SystemWindow has several ivars that are
associated with the window label and control boxes, such as label, closeBox,
collapseBox etc. Each of those morphs are stored in the SystemWindow
submorphs list, with a 'cached' handle in the ivar. That's fine, but what
happens when you try to change the structure of a SystemWindow instance? (In
my case, I would like to remove all of the instance variables related to the
window frame, this would work smashingly well for new instances of
SystemWindow, but the existing instances would be *very* disappointed with
my change and would probably tell me about it with cute little pink
dialogs).

In my case, I'm trying to 'rearrange' selected submorphs of the SystemWindow
by grouping them a little differently into what I'm calling a WindowFrame.
However, since many of the morphs are stored as instance variables, I can't
just remove those instance variables without having to do major surgery
reconstructing already existing instances of SystemWindow (and even worse,
subclasses). This is bad because the physical structure of the morphs is
already maintained dynamically in the submorphs list, which has no bearing
on the much more static object instance that was responsible for its
construction.

One solution is to refer to a submorph by a name using #submorphNamed: . If
you really need fast access to a particular morph, place it in a property to
cache it. Remember that a property is a dynamic list, so it doesn't have
nearly as many long lasting consequences as defining an ivar does if you
later go back and try to deconstruct/reconstruct already occuring instances.

My goal here is to keep dynamic dynamic and place as little structure in
there as possible. Under this scenario, you'd address the different morphs
by name, e.g. 'windowFrame submorphNamed: #statusBar', or you could stash
the statusBar into a property and examine it as 'windowFrame
valueOfProperty: #statusBar' (I'm tempted to rename valueOfProperty: to just
#slot)

> PPS>  If additional window attributes are added (per my PS), it may also
be
> desirable to add some run-time configuration capabilities to WindowFrame.
> e.g. show/hide menu/toolbar/status bar/flaps, set fonts for
> title/flaps/status bar, etc.
>

I think of this is as the appearance manager, and is related to my attack on
Preferences.

My current thinking is that I just supply a list of all the morphs that I
want to add to the window frame, and WindowFrame assembles the morphs from
the list. It doesn't really matter which type of morph you want to add, just
as long as you can specify how to construct it and where it goes. Where it
goes is a little more involved as it involves the basic layout mechanism of
Morphic.

As far as I can tell, there are at least two tricky parts with WindowFrames,
one of which is to tell the client window what the bounds are to display the
content area, the other being the protocols between the frame and the window
itself.

What I'm hoping is that when I start throwing out code for this, other
people will take a look and start improving from the basic ideas. If some of
the basic ideas are flawed, then I'll work on fixing them.

Jim