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

I guess this isn't a big deal for most windows, but it is a problem for Whisker, which does its auto-resize thing on the subpanes.  The bottom pane in a stack of panes gets shortened by an extra titlebar-height, which does nothing for its self-esteem.  As if it weren't already depressed enough about being stuck on the bottom, to get shortened like that... (sorry, it's late).

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.

I've put off trying to fix this in the 2.9 version of Whisker for now, hoping that it would get addressed in the base image at some point.  (I guess I could try to address it if no one else does...)

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

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

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

- Doug Way
  dway at riskmetrics.com