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

----- Original Message -----
From: "Daniel Joyce" <daniel.a.joyce at worldnet.att.net>
To: <squeak-dev at lists.squeakfoundation.org>
Sent: Thursday, October 10, 2002 10:56 PM
Subject: Clipping and scrolling


> Someone was mentioning that clipping and scrolling could be slow on
> large lists because the scrollpanes still redraw all their internal
> morphs, and then just clip down...
>
> Well, the morphs themselves have obscene, Morphic's layout has
> definitely improved, buut, there are some insane internals...
>
> List item morphs, for example, have their rightmost xbounds at 9999!
>
> And this supposedly set from somewhere inside when they recompute their
> bounds. Shouldn't a list item set it's right bounds at the edge of
> morph that contains it?
>
> I'm trying to track down where this weirdness comes from...
>
> -Daniel
>
>