Re: Sizing...

[Maciej Stachowiak <mjs eazel com>]

Miguel de Icaza <miguel@helixcode.com> writes:

> The whole description of the problem is too confusing from your mail
> Michael, I could not understand what you are trying to do.
> 
> Could you please summarize it in less lines?
> 
> > This sounds like you are implying that Controls should be
> > self-scrolling (if they need scrolling), while Embeddables should be
> > scrolled externally. Am I understanding correctly? If so, I see at
> > least one problem that you didn't already cite below.
> 
> I do not think we want Controls to be self scrolling.
> 
> It is up to the container to:
> 
> 	1. Set the size for the control.
> 	2. Set its zoom factor.
> 
> The container chooses whether it will add a scrollable feature or not
> to the internal control.  This is not something the control can do on
> its own.

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.

> For instance, I would expect Nautilus to launch the component that
> makes the most sense for displaying images (scaled to whatever space
> they have there) and let the container export a Verb that can be used
> to configure the view (`fit to screen, fully expand') and so on.

We don't want the image to scale to the space we have in Nautilus. We
want it to show at it's natural size, and allow the user to scroll
around if this is bigger than the available display area. I don't
think it is unreasonable to want this kind of UI. We also want text
documents to behave this way, for instance.

What I would like to know is how to handle both of these two cases in
Nautilus at once:

* Embed some control or embeddable that is self-scrolling (not that
  Nautilus knows this - there is no API to export this info), and have
  it provide it's own scrollbars when it is larger than the viewable
  area, without Nautilus adding any.

* Embed a control or embeddable that is non-self-scrolling, and have
  it show up at natural size, but with scroll bars added by Nautilus,
  and without the scale factor being affected.

I do not see any way to handle both these cases correctly at once
using the current Bonobo APIs.

 - Maciej