Re: BonoboZoomable ...



on 4/19/01 11:11 AM, Michael Meeks at michael ximian com wrote:

> I really don't like the Zoomable / ZoomableFrame interfaces, I
> think they are needlessly verbose, and complicated in their use.

I agree that the interfaces are needlessly complex. This is largely because
they have the part that is needed for actual use in Nautilus, and a bunch of
stuff in there is just theoretical and has never been used.

> Furthermore, they don't interact at all well with the UI handler
> stuff, inasmuch that a user now needs to do:
> 
>     merge_ui_1 ();
>     if (!frame_supports_zoomable)
>         merge_custom_zoom_items ();
> 
> Which sucks.

The Nautilus user interface has a specific placeholder where the zooming
menu items should be merged. But there's no way in Bonobo to have components
merge into that placeholder unless they know the full path, which means it
has to be in the View menu in every application. This could be addressed by
changing the Bonobo UI framework to use global names for placeholders
instead of using full paths.

If we always merge in the same user interface everywhere, then assumes that
the same UI is appropriate everywhere. In Nautilus, where most viewers are
expected to support zooming, it's appropriate to always use a toolbar item.
In other programs, it might be better to just have menu items. Similarly, in
some programs there might be keys available for the zoom commands, but in
other those keys might already be taken for commands that are more important
for that application.

> I would prefer instead to ensure that all apps have access to the
> nice nautilus zoom widget, and standardize a 'Zoom' location, and have a
> control merged to that place.
> 
> Clearly having a property on the control to allow the setting of
> the zoom level programmaticaly ( by scripts etc. ) would also be nice.

This means that each control would have to separately implement both the
zoom widget and the programmatic control. I think this duplication is
unnecessary extra work. Programmers should only have to do the programmatic
control, and the widget should materialize automatically. Of course this can
be done with a different interface if we don't like BonoboZoomable, using
properties if that's the best way.

Note that a property on the control would give a way to get and set the zoom
level, but would not give a way to do other important operations
programmatically, such as "Zoom to Fit".

> So ... I'd like to drop these interfaces, but it's important to
> get consensus on this from Nautilus, since otherwise we'll get a nastily
> inconsistant setup.

Clearly dropping the interfaces would have little effect on programs other
than Nautilus, because they aren't using the interfaces! I think that
removing the interfaces should be done only *after* we implement an
alternative. If you remove the interfaces first, then we *have* to do that
work to convert Nautilus to GNOME 2, which means less time to work on other
important features.

> Input welcome,

Here are some of the practical repercussions of making this change that I
can think of right away (I don't have much time to spend on this, so this
list is not exhaustive):

    1) It's a substantial code change for Nautilus and a minor code change
for all the existing modules that support zooming to remove the zoomable
interface.
    2) The zoom control is currently themed along with the rest of Nautilus
by the Nautilus theme. I'm not sure how to make sure that the control uses
an appropriately themed version of the zoom widget.
    3) The location of the zoom control in Nautilus is currently in a
toolbar that is not managed by Bonobo. We'd have to make code changes to
make the entire location bar be a Bonobo toolbar, which might entail adding
additional Bonobo features. Since we are not planning to port Nautilus to
GNOME 2 until after an API freeze, this could cause a bit of trouble because
it would be too late to add such features to Bonobo.
    4) With this change, the zoom control would likely disappear and
reappear as we switch from one component to another. We'd have to carefully
tweak the view-switching process in Nautilus so it stays put and seems to be
the same control.
    5) Using the Bonobo UI framework does not really eliminate the issue of
needing a special case. I'm not sure that every program that might host a
control that supports zooming would have a suitable place in the toolbar for
a zooming widget. If the widget was put into the toolbar using a placeholder
that was intended for use with Nautilus, it might end up in a strange place
in other programs.

Here are some of the advantages I see:

    1) One less class to explain in Bonobo documentation.
    2) It would be much simpler to not have an additional interface on each
Nautilus View.
    3) The Nautilus adapter can be simplified as well, since it no longer
would need to proxy the zoomable interface.

I think that overall we would have been better off if we had kept these
interfaces as Nautilus-specific ones and this not had the impetus to refine
this minor feature. We are wasting time on this issue while we could be
spending it on things that are far more important for a good end user
experience. The way it is now works. I'm not sure that this change would be
an improvement overall, but even if it is, it might not be worth all the
code churning required.

    -- Darin





[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]