Re: Proposal of a Bonobo::Zoomable interface

[Martin Baulig <martin home-of-linux org>]

Miguel de Icaza <miguel helixcode com> writes:

> > > Zooming as implemented in Bonobo is there for using in compound
> > > documents, and you really should support that in your component if it
> > > is supposed to be part of an embeded document.  
> > 
> > Unfortunately, it is for this reason not at all useful for Controls.
> 
> Oh.  I did not know this was a feature for Controls.  
> 
> It sounds like a nice idea for the Nautilus framework, but I fail to
> see this as a generally useful thing in a GUI toolkit.  Indeed, I do
> not remember seeing any kind of Zoom support in any toolkits out there
> (with the exception of the Postscript-based toolkits, which handled a
> more general affine-based case to begin with).

Dude, I'm not talking about Nautilus here, but about a generic zooming
interface which will be useful for all container applications.

Nautilus is not the only application which is able to display/embed controls
and the more popular Bonobo will become the more container applications we
will get. We can't expect all components to provide specialized zooming
capabilities for all possible container applications.

> So I feel like this does not belong in Bonobo.

Having this in Bonobo will allow

a) component writers to add zooming support to their components which will
   make them zoomable not only in Nautilus, but in all container applications
   which support zoomable components.

b) container application writers (sure, currently this is only Nautilus, but
   we'll get more of them in future) to easily find out about the zooming
   capabilities of a component.

> This is just my gut feeling: that it might be a nice idea that is
> being explored in Nautilus, but it is not yet a tested enough feature
> to go into Bonobo (like a few features in GnomeLibs that we later
> found out were nice ideas, but really useless in practice, like, say
> all the features in the PropertyBox).

Well, I think it's not yet tested enough since nobody really wants to make
a small component like the eog image viewer depend on libnautilus just to
get zooming support for one single container application (Nautilus).

> > For a compound document this might make sense. In a Control context,
> > or a case where you areuisng an Embeddable in a Control-like way, the
> > component itself may have some internal UI for setting the zoom level
> > (perhaps it merges a control onto the toolbar; perhaps it has a right
> > click menu). In any case, set-only interfaces are generally not the
> > best design. For instacme, the component may have been passed to you by
> > someone else who intialized it to a particular zoom level; it would be
> > annoying to have to also pass the zoom level in that case.
> 
> Good point.  What about exporting a PropertyBag for letting people
> peek at your settings from the container?

I thought about this after Torstens mail but I came to the conclusion that
this'll cause more trouble (since you need to deal with incorrect/half-set
properties etc. and you also really need to have _one_ notifier call after
the application finished changing all the values) than it's worth.

-- 
Martin Baulig
martin gnome org (private)
baulig suse de (work)