Re: Proposal of a Bonobo::Zoomable interface

[Maciej Stachowiak <mjs eazel com>]

Federico Mena Quintero <federico helixcode com> writes:

> 
> But let's talk about controls, which are where you may want a zoomable
> interface.
> 
> I don't think having a generic zoomable interface for controls would
> be very useful.  You'll have something that is too generic and yet it
> will not meet the needs of some application.
> 
> I think it is better if the control just exports the UI elements it
> needs to allow the user to change zoom factors.  EOG or a 3D modeller
> may want an SGI-like knob or dial thingy; a web browser may want a
> little control to set the font size in points; the Nautilus icon view
> may want a simple menu with "big/medium/small" settings.  A mapping
> program may want to have two controls; one for the size of labels and
> one for the scale of the map.

The reason for having a Zoomable interface is to have a common,
consisten UI, i.e. the exact opposite of what you advocate. In
Nautilus, we activate or deactivate the zoom control based on the
presence of zooming support, rather than having it appear and
disappear all the time. Even if it were desirable for some components
to have different custom zoom controls, it would not be desirable for
the zoom control to temporarily disappear when you switch between two
different views that use the same one (for instance the Nautilus icon
and list views). So I think the ability to do this generically makes
for better UI in some ways, even if in some special circumstances, a
custom approach could be helpful. Really, there seem to be only two
basic cases, a fixed set of discrete zoom levels, and continuous
zooming. 

In the map example you cite, zooming labels and the map independently
would be of questionable merit, but it seems clear to me that even if
it were useful, the map should be controlled by the primary zoom
control, and the labels by an auxiliary control. (The fact that
Mapquest doesn't have a method for zooming the labels at all convinces
me it's of peripheral importance at best).

> So you see that this cannot be made very generic.

The main thing the Nautilus zoom widget does not handle very well
right now is things that are continuously zoomable. For that, a slider
or knob would work better than the current widget. However, I can
easily imagine a widget that adapts well to either circumstance.

> If the toolbar is the proper place to put these app-specific UI
> elements, then the Bonobo toolbar stuff should allow for little
> child-defined controls to go there.  I don't recall if Michael's new
> design allows for this, but I would assume so.
> 
> The discussion I had with Maciej about a zoomable interface may only
> apply to EOG; at least that was the context I was thinking in.  Sorry
> if it caused confusion.

Well, we are using the interface for the icon and list view in
nautilus. It seems like it would apply rather sensibly to image, PDF,
plain text, html, vector graphics, postscript and 3-D model, movie,
etc views as well (with some tweaking of the UI for the zoom
control). That seems pretty general-purpose to me. I'm sure there will
also be special exceptions, but then, there are probably cases where
GtkButton is not the right pushbutton widget.

 - Maciej