Doug Way wrote:
> 
> Jesse Welton wrote:
> > 
> > As noted in the comment of Morph>>addMorph:fullFrame:, there is an
> > inconsistency between the meaning of layout offsets between ordinary
> > Morphs and SystemWindows.  This is emphasized by the fact that
> > SystemWindow>>addMorph:fullFrame: actually negates the bottomOffset
> > (in addition to adjusting it to take the title bar into account) --
> > but only when the bottomFraction is not 1.0!
> 
> I hadn't noticed the negating problem, oof.  Somebody ought to do
> something about this, for the love of God. (ok, I'll tone down the
> melodrama.)

I'll see what I can do, but for other reasons than you suggest.  :)

> I did notice the title bar problem, though.  This makes it difficult
> to specify, say, a SystemWindow with two subpanes, one above the
> other, such that the border between them is 50% of the way down (so
> that the subpanes are equal in size by default).  Instead, the
> border is offset by the titlebar height.  The layout frames for the
> subpanes are based on the entire SystemWindow morph, when it would
> be better for them for them to be based on the non-titlebar portion
> of the SystemWindow.  (Right?)

Yeah, absolutely.

> Anyway, my guess is that the best way to address this is to have
> some sort of "contents" submorph in SystemWindow which would be the
> area of the SystemWindow minus the titlebar.  Then the paneMorphs
> would be submorphs of this contents morph, so that their layout
> frames would apply to this area, avoiding the whole titlebar offset
> problem.  This might be a bit of work, but seems doable.  There may
> be other ways to solve this, too.

The alternative that comes to my mind is for the SystemWindow to
override its submorph layout routines to adjust the top of the
rectangle in which submorphs are asked to compute their layout.  Hmm,
that might affect the title bar, though...

> > This should really be cleaned up.  I'd set to it straight away, but to
> > make matters worse, it looks like LayoutFrame in fact wants to treat
> > the offsets as insets, causing me significant cognitive dissonance.
> > So: should "offsets" be offsets, should "offsets" be insets, or should
> > the name be changed so that "insets" are insets?
> 
> Hm, I hadn't actually used the rightOffset or bottomOffset, so I
> hadn't noticed this.  (I just assumed they all increased down and to
> the right, which I guess isn't the case.)

That's what I thought, too.  And my reaction is that offsets seem more
intuitive to use here than insets, too.  The existing code seems to
bear this out (see below).

> But you're right, they are insets, so I think your third option is
> probably the best.  It involves a bit of renaming, though.

I'm not at all certain of this.  In the image, the offsets seem to be
used mostly by Browser, which definitely seems to treat them as
offsets rather than insets.

Example, from Browser>>addOptionalAnnotationsTo:at:plus:

    window 
        addMorph: aTextMorph 
        fullFrame: (
            LayoutFrame 
                fractions: fractions 
                offsets: (0 at verticalOffset corner: 0@(verticalOffset + delta))
        ).

And from Browser>>addAListPane:to:at:plus:

    row 
        addMorph: aListPane
        fullFrame: (
            LayoutFrame 
                fractions: (0 at 0 corner: 1 at 1) 
                offsets: (0 at 0 corner: 0 at switchHeight negated)
        ).	

    self 
        addMorphicSwitchesTo: row 
        at: (
            LayoutFrame 
                fractions: (0 at 1 corner: 1 at 1) 
                offsets: (0 at switchHeight negated  corner: 0 at 0)
        ).

Note that the bottom offset is in both cases matched in sign to the
corresponding top offset.  Now, how it happens that this actually
*works*, I haven't traced yet...

> (Despite the griping in this message, I'm glad that LayoutFrames
> were added in 2.9a... there just seems to be some cleanup work to be
> done.)

Oh, absolutely.  The new layout stuff is wonderful.

-Jesse