Re: Proposal of a Bonobo::Zoomable interface

[Miguel de Icaza <miguel helixcode com>]

> > 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).

So I feel like this does not belong in Bonobo.

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).

> 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?

Miguel.