WindowFrame design
Lex Spoon
lex at cc.gatech.edu
Fri Jul 13 17:24:26 UTC 2001
> > You say "structure" as if it were a bad thing! It seems better to
> > decide how dynamic each property should be, instead of making every
> > property completely dynamic.
>
> >From my perspective, duplicating structures is a bad thing. Submorphs are
> not 'properties', they are part of the substructure of the morph being
> defined, and are already stored in the submorph list. I don't think they
> should be cached on a routine basis. I'll go back to the case of the
> SystemWindow. I'm not picking on SystemWindow, just using it as a reference
> as it seems pretty typical of an evolving morph in Squeak.
Ah. I completely misunderstood your angle -- I thought you were trying
to make major rewrites of SystemWindow be easy, even if the result isn't
as nice. Instead, you are trying to eliminate redundant instance
variables--this is certainly a wonderful goal!
>
> I'm probably looking at this from the other way around than you. I've been
> trying to think of Morphic as the reification of objects on the screen. When
> I look at a SystemWindow on the screen, I can see if it has a close box. If
> it has one, I can open an explorer and examine the structures. From that
> perspective, there is no advantage in having the close box cached in an
> ivar, and for me the less duplicate structures the better.
You seem to know this code more than I do, but at a glance it's not
completely obvious that closeBox, et al, are unneeded. Using inst var
refs, I see:
closeBox - after SW creation, the closeBox gets enabled and disabled
every once in a while.
collapseBox - ditto
labelString - needed to relabel the window after it's created
The alternative, I suppose, is to go searching through submorphs looking
for an item. This has some appeal -- it does eliminate a little
redundancy, and it means you can dissasemble and re-assemble morphs more
freely. However, how should the seerch be done? I guess I'll have to
reread your proposal, but for things like closeBox which will always be
there, making it more dynamic doesn't seem like a big win. I guess it
*is* pretty neat if you can drag off the close button of a window to
make it harder to close, and that you can later add any old close button
back to a window and that close button will work (for this latter, one
will want to search owners, not submorphs!).
Neat stuff.
Lne of code of the day:
Preferences noviceMode ifTrue: [m lock] ifFalse: [m lock]
Heh :)
-Lex
More information about the Squeak-dev
mailing list
|