GNOME Bugzilla – Bug 77952
Nautilus zoom widget should be a standard gtk widget
Last modified: 2004-12-22 21:47:04 UTC
The galeon zoom widget is a lot nicer than the nautilus one. It allows you to change the zoom to any integer value via a text entry box and uses standard gtk widgets so that it is themable directly by gtk. This would do alot to improve nautilus integration into the gnome look defined by the user via gtk here's a bad ascii drawing ____ | | /\ |____| \/
Even better, maybe we can make this widget a standard gnome or maybe even gtk widget so that all gnome/gtk programs can use it.
I'm going to remove the 'more like' :) They should both use a standard widget, whatever that is. Obviously future, though. Jody, I know you've discussed some common-widget stuff like this in the past; is there a list somewhere of what widgets are needed/desired?
There is yet another version of this in gal used by gnumeric. We hope to get a blessed common set of combos in the future versions of gtk. Design discussion is underway on gtk-devel
just to add my 2 cents. I think the galeon zoom widget is nicer than the gnumetric one, since it allows users to increment or decrement the zoom by steps of 10%.
*** Bug 40839 has been marked as a duplicate of this bug. ***
The nautilus zooming framework in both the icon and list view doesn't allow for 10% zoom steps, only the hard-coded set is supported.
Thought i add that i think the gtk spin button is the widget i'm thinking of, assuming the issue that anders' presented can be addressed. I really think it would be cool if the user could choose any zoom level.
bill, this is an accessibility issue right, since the nautilus zoom widget is themed by the nautilus theme not by gtk. changing the title a bit.
for what it's worth, I don't care if this is a standard gtk+ widget or not, so long as it is "accessible", i.e. it exports appropriate ATK interfaces (AtkAction if it accepts only specific zoom factors, and/or AtkValue if it allows arbitrary zoom factors) and respects the GTK+ theme. In order to respect the gtk+ theme it needs to either use gtkstyle.c primitives for its drawing, and gtk_icon_factory for its images, or it needs to read appropriate values from gtkstyle and gtksetting and then do something compatible. The key attributes it needs to observe are font size, colors, focus line weight, and icon size, and the icon it uses for the magnifier should be re-specifiable in an RC file like the gtk stock icons. In practice this may mean that making the zoom widget a close derivative of a standard gtk+ widget, or using standard gtk+ widgets as-is, would be the most expedient way of meeting these goals. This is nice for everyone, not just a few users, since it means that the file manager would integrate nicely with the users' current application theme and not just do its own thing visually.
Created attachment 11525 [details] [review] Patch: Implementation of the zoom-control as a combination of standard gtk components
Created attachment 11526 [details] [review] Tooltips added to the patch (don't know if the user defined accessibility is needed)
adding patch keyword, although the "right" solution here is still to standardize on the gtk zoom widget (once it exists). Note that this is probably important to fix before naut themes disappear, since that will mean that the zooom widget becomes entirely unthemeable.
As David said, now that Nautilus themes are gone, we really need themeability for this widget.
Updating status_whiteboard field to reflect A11Y team's assessment of accessibility impact.
something else went in but thats ok.