Window Frames for system windows

Norton, Chris chrisn at Kronos.com
Fri Jul 21 15:09:12 UTC 2000


Hi Jim.

Jim Benson wrote: 
"Part of this bug is the way that the AlignmentMorph draws. If you look at
the method:

AlignmentMorph#drawSubmorphsOn:

You'll notice that it clips to the bounds of the owner Morph. In a
SystemWindow, that includes the frame area. Consequently, the frame area
gets over written. Note that this is also true of a SystemWindow without the
window frame code filed in, in the example that you have a border width > 1
for a regular SystemWindow. One solution is to check if the owner is a
SystemWindow and ask for the inner bounds, but I'm not sure what the general
purpose solution should be. I'd like to hear suggestions. I would think that
you always want to write within the borders of the owner morph, but I don't
know what the consequences of that are."

[Chris Norton]  I haven't given this much thought, but it strikes me that
submorphs should never be allowed to write beyond the bounds of their
owners.  Given that assumption, it would seem to me that all owners should
support an "innerBounds" or a region that their submorphs can freely step
on.  If all morphs support the "innerBounds" convention, then any given
morph can only resize up to the size of it's owner's innerBounds.

What do you think?  I think this should be a convention that all morphs
subscribe to.

Cheers,

---==> Chris







More information about the Squeak-dev mailing list