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!
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?
-Jesse
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@riskmetrics.com
On Sat, Jan 27, 2001 at 01:31:52AM -0500, Doug Way wrote:
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).
I'd noticed that, but had assumed that it had to to with the weight of all of the other windows piling up, thus causing the bottom one to squish down.
(sorry, it's early)
Joshua
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
squeak-dev@lists.squeakfoundation.org
-
Doug Way -
Jesse Welton -
Joshua Channing Gargus