Jesse,



>
> What I'm most interested in, with this, is
> actually to refactor the resizing behavior of SystemWindows and their
> subpanes without being tied to any particular appearance package, but
> in a way that would make the production of appearance packages easier.
> Do you think it makes sense to separate out the resizing behavior
> you're working on and apply it to SystemWindows without the skins?
>

You've must have been thinking about seperating the view from the controller
;)

This window resizing mechanism should not rely on the appearance of the
window frame. Conceptually, I want to just define some 'invisible' resizing
morphs that know how to talk to the window being resized, place them in the
correct layer of the SystemWindow hierarchy, and be good to go. Much like
the little examples I've been coding up. This also affords the opportunity
to simply add such things as a resizer at the bottom right hand corner of a
window, similar to the grow box on a Mac. I've rather sidestepped the issue
of how you go about actually defining a general case description of these
resizers (like an XML layout or some such).  Also, I haven't show how to do
pixmap edges just yet.

While I've been using simple uniformly sized edges, you can also create
resize edges each a different size. This is useful for pixmap based frame
borders where one edge is a different size than the other.
As a simple example, in the latest code you can set the topLeftInset and
bottomRightInset of the frame box to define the rectangular region where the
window pane sits. In WindowFrameMorph>>#addDefaultFrame the last two lines
define this. You can change

 self topLeftInset: 4 @ 25.

 to:

self topLeftInset: 32 @ 32.

Obviously you need to reset the left edge resizer to cover the new area
(which I'll leave as an exercise ;-) but I think you get the idea. Typically
you'll see this used in fancy pixmap schemes that have one border wider than
the other.

You can apply these resizers to the current SystemWindow. However, since the
border size on current SystemWindows is only one pixel, it doesn't get you
very far and carries a lot of overhead for no real gain. For this
subproject, my goals are two fold. One, make a border on a window which I
can actually grab (4 pixels wide in my case), and two make a window frame
which is more functional in my environment. For me, this means a "taller"
label area with bigger buttons. I know that SystemWindow allows for taller
label heights, but I haven't figured out how to use it in the general case.
I've been using different versions of this code for a few months now, and it
seems to be easier for me to use than stock.


>That would feel more like a pull-down menu.  Wasn't there
> someone on the list working on a MenuBarMorph recently?
>

I'd like to meet the jerk who wrote that code.

> > Next up, refactoring SystemWindow to refactor the frame elements into
> > another class.
>
> You mean the frame as drawn, yes?

I'm taking the label elements currently stored as ivars in SystemWindow
(labelString, stripes, label, closeBox, collapseBox, menuBox, labelArea,
expandBox, labelWidgetAllowance) and refactoring them into their own class.
Just a general cleanup to tidy things up a bit. Currently, all of the window
frame elements are pretty much tangled up in the SystemWindow code, and I
would like to extract them and send them out on their own.


> Meanwhile, I've started working on
> factoring out the pane resizing.  (Actually, I'm working on the
> preliminaries now, refactoring your two window border classes into a
> common superclass for both those behaviors and that of pane resizers;
> and I'm removing the dependence on NewHandleMorphs, which is just
> complicating things.)  I'll let you know when I have something worth
> looking at.
>

Great !!! Looking forward to it.


Jim