Already approved by Daniel, should probably wait for 3.7alpha though.

Actually, there was some discussion between Eddie and Ned below which 
I'm not sure was resolved.  I'll assume Eddie's original version was 
approved unless I hear otherwise.

- Doug


Eddie Cottongim wrote:

>I think that both #localSubmorphBounds and #localVisibleSubmorphBounds are
>reasonable and should be answered accurately. Either one can be cached
>depending on what clients need.
>
>You'd have to be careful caching #localVisibleSubmorphBounds. If one of the
>submorphs becomes invisible/visible, the cache needs to be invalidated. I
>think if you made Morph>>visible: send #layoutChanged, it would work. The
>layout hasn't really "changed", but it seems to be necessary to catch that
>event.
>
>So, which one should be used for scroll range? Well.. I guess using
>localVisible doesn't hurt. I don't really like it, because its sort of
>deceiving the user about how much stuff is in their scrollpane, but I can't
>say that someone wouldn't want that behavior. Maybe you have some list, and
>items are removed from it (esp. the beginning/end), and you want the
>scrollbars to adjust.
>
>You can have it either way, but I'd prefer to get accurate answers out of
>both methods, and yes, either way, some clients will be needing adjusting
>since they use both methods right now.
>
>Eddie
>
>----- Original Message -----
>From: <ned at bike-nomad.com>
>To: <squeak-dev at lists.squeakfoundation.org>
>Sent: Saturday, July 26, 2003 1:35 PM
>Subject: [ENH]TransformMorph caching ( do we need to account for invisible
>morphs? )
>
>
>  
>
>>This looks OK, but I noticed that the code for computing the bounds is
>>more or less the same as in TransformMorph>>localVisibleSubmorphBounds
>>(or for that matter Morph>>submorphBounds). Which raises this question
>>(which is really more a question about the code changes I did back in CS
>>4836, back in 4/2002):
>>
>>The new version could almost be rewritten as:
>>
>>localBounds
>>^localBounds ifNil: [ localBounds _ self localVisibleSubmorphBounds ].
>>
>>EXCEPT...
>>
>>the one difference is that #localVisibleSubmorphBounds accounts for
>>invisible submorphs, and this code doesn't. So if the first or last few
>>morphs aren't visible, you'll get a different extent for submorphBounds
>>and localSubmorphBounds. Since #localSubmorphBounds is used to compute
>>the scroll range, it seems to make sense that you'd want to account for
>>invisible morphs.
>>
>>So my suggestion is to use the above code instead. Unless someone can
>>think of why we'd want to ignore the invisible morphs sometimes and not
>>other times. I can't remember why I did this, now.
>>
>>And if we do that, we should change the callers of
>>#localVisibleSubmorphBounds to use #localSubmorphBounds instead to take
>>advantage of the caching.
>>    
>>
>
>
>
>  
>