Re: Sizing...

[Lauris Kaplinski <lauris helixcode com>]

Doesn't the invariant:

component will handle scrolling, if activated in-place

solve half of the problem. Notice, that in all mentioned cases we are
talking about uses, where component can be considered
activated. Container-side scrolling should be applicable to
inactive components (which can be treated like huge images)
The other half is sharing scrollbars, so there won't be duplicates.

I cannot tell, whether activation semantics allows such meaning. But
following examples seems logical:
If EOG is used as image viewer, it is activated, so user can zoom and pan
If EOG is used as image object, is it inactive

Lauris

On 27 Jul 2000, Maciej Stachowiak wrote:

> The problem with this approach (making the container always handle
> scrolling) is that controls often have good reason to want to scroll
> themselves, or in some cases need to, to get correct semantics, and
> cannot be scrolled externally.
> 
> * Consider EOG - Federico has added nice diagonal scrolling support
>   through "hand cursor dragging". Once the EOG component is updated to
>   match the main EOG app, we will want to support this feature too,
>   but it can only be done if you self-scroll.
> 
> * Consider a control based on the CList, like the Nautilus List
>   View. It has to scroll itself because you want only the list
>   contents, not the headers to scroll. This would also apply to
>   embedding a gnumeric cell range or full spreadsheet that you want to
>   be scrollable - scrolling of the row and column labels would have to
>   be handled specially.
> 
> * Consider a Mozilla control, or anything based on GtkLayout - it
>   _has_ to self-scroll, because the rendering/scrolling model is not
>   based on rendering into a large X drawable and then moving it around
>   and generating exposes. I think this might be true of the canvas as
>   well.
> 
> * Consider a component for a word processor that would like to scroll
>   down by a page in response to a Page Down keybinding, or a merged
>   menu item. Only the component knows how much a "page" is, so this
>   feature cannot be provided by the container.
> 
> * Consider a component that wants to scroll it's viewable area when
>   doing a drag-selection, such as the Nautilus Icon view. This can't
>   work with container-side scrolling either.
> 
> So at least some components need to self-scroll, either to provide
> certain features, or to scroll correctly at all. Thus, any solution
> that requires all scrolling to be done container-side is not a
> complete solution. In fact, it seems that only a very few extremely
> simple components can work properly with container-side scrolling.