On Wed, Jul 11, 2001 at 01:50:48PM -0700, Jim Benson wrote:
> 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).

This (at least in some cases) is not terribly difficult.  I just had to do it
to integrate Cassowary into Morphic.  Replace each get/set of variable foo to
a send of #foo/#foo:.  Make the methods do the simplest thing: a direct get/set
of foo.  Then, replace the direct gets/sets with the appropriate dynamic 
computation.  Once you are getting the same behavior as before, just remove
the ivars.

> 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. 

Cool approach!  I had never benchmarked property access, but a simple test shows
a ballpark speed of 0.2ms/access; that's much faster than I'd thought.  I'll 
definitely keep an eye open for opportunities to play with this.

> 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)

I agree; If you intend to use this approach fully, a less verbose protocol is 
essential.  Perhaps Morph>>set: could be renamed (it is currently use to set 
position for eToys).  You could then have:

aMorph get: #aProperty
aMorph has: #aProperty
aMorph delete: #aProperty    (maybe not the best name?)
aMorph set: #aProperty to: aValue

This would be considerably nicer if you plan to use properties extensively.

> 
> > 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.
> 

May they crumble and fall!  :-)

> 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.
> 

I like that.  It makes for literate morphs as well.  Right now, a PluggableListMorph
in a Browser identifies itself as 'PluggableList'.  If your window frame assembles
its components by name, a nice side effect is that people poking through the window
with halos can see names like 'Class List', 'Method List', and 'Comment Button'.

At the risk of frightening you, THIS IS GREAT STUFF!!!!  I ABSOLUTELY LOVE IT!!!!!!

;-)
Schwa

> 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
> 
>