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


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.

-Daniel