Re: Proposal of a Bonobo::Zoomable interface

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

Maciej Stachowiak <mjs eazel com> writes:

> Miguel de Icaza <miguel helixcode com> writes:
> 
> > > Currently, there is no good zooming interface in Bonobo.
> > > I mean, there is this "set_zoom_level" signal on a BonoboView,
> > > but there is no way for a container application to
> > > 
> > > a) find out whether a component supports zooming
> > 
> > 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.

Well, Bonobo is not just for compound documents, but also for Controls.

There are also components where it makes absolutely not sense to support
zooming - for instance a shell component.

And some other components may not support continuous zooming but only
a few fixed zoom levels or they may have constraints on their minimum and
maximum supported zoom levels.

For instance, for a shell component, it would be nice if it could support
some fixed "zoom" levels each of them representing a particular font size -
thus when you embed the shell component into a container application like
nautilus, you could use the "zoom" control to change the font in the shell
(and since this makes the contents smaller or bigger, I'd call this some
kind of "zooming").

> > > b) ask the component for its current zoom factor
> > 
> > You always set this, or you should be able to keep track of this
> > without requiring the embedded piece to report this
> 
> 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.
> 
> > > c) ask the component about its zooming capabilities, for instance
> > >    if it has a minimum/maximum zoom factor, if it only supports
> > >    fixed zoom levels etc.
> > 
> > This seems like it will bloat every application.  Now every
> > application will have to query its components and find out what sizes
> > the embedded is happy to deal with.
> 
> Well, again, this might be excessive in a compound document context,
> but not for other uses.
> 
> > When the right thing to do is to have every component support zooming
> > at every resolution possible.  
> 
> Sometimes that is not feasible or desirable. Stepwise-zoomable
> components already exist in any case, it's just a matter of whether
> they will be supported only by Nautilus, or by any app that uses
> Bonobo. The Zoomable interface in Nautilus is pretty general, and was
> even blessed by Federico at one point, though, so leaving it a
> Nautilus-only thing might not be the most useful approach to the
> problem.

Having such a generic Zoomable interface in Bonobo will also make it easier
for developers of components; they don't need to worry about all possible
container application and special-code for each of them, but just implement
the generic zooming interface.

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