Clipping and scrolling
daniel.a.joyce at worldnet.att.net
Fri Oct 11 04:58:43 UTC 2002
On Thursday 10 October 2002 11:51 pm, Eddie Cottongim wrote:
> The width is set like that, I think, so that list items will always
> be at least as wide as their list. This simplifies some things like
> item click processing and drawing the highlights. I suppose when we
> start using displays > 9999 pixels wide we'll have to change it!
> Since Lists have only vertical scrollbars, the width of items is
> never queried. If you wanted horizonal scrolling too, this would have
> to be changed.
> So it doesn't seem to hurt anything that I can see.
> One thing I'll point out is the call to Morph>>bounds from
> PluggableListMorph>>list:. This boils down to separate calls to
> position: and extent:. Each of those sends layoutChanged:. Once ought
> to be enough. Since bounds: is called a lot, it might be worth
> getting that down to one call. I'm not sure how expensive each
> layoutChanged is.
Well, this is what I mean. Morphic is full of this weirdness.
Is this hack true for all widget sets, or just morphic?
When damaged, does the ListItemMorph just redraw that which appears
inside a list, or does it redraw EVERYTHING out to xpos 9999 (thus
eatting processing power) and the parent clips it?
Also, maybe it's just me, but parents are supposed to send layout
changed and other goodies to their kids. It's the only way to make sure
buttons/boxes don't hang outside of their parents ( I see this a LOT in
Squeak, try 22pt Atlanta, and see what happens, I need this large font
to see the text on my hires display ).
Clipping, bounding, and other things are a mess in Morphic... >.<
Plus it's ugly and unprofessional looking.
More information about the Squeak-dev