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.