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@verticalOffset corner: 0@(verticalOffset + delta)) ).
And from Browser>>addAListPane:to:at:plus:
row addMorph: aListPane fullFrame: ( LayoutFrame fractions: (0@0 corner: 1@1) offsets: (0@0 corner: 0@switchHeight negated) ).
self addMorphicSwitchesTo: row at: ( LayoutFrame fractions: (0@1 corner: 1@1) offsets: (0@switchHeight negated corner: 0@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