GNOME Bugzilla – Bug 321867
Honour the GNOME detachable_toolbar gconf key
Last modified: 2008-03-10 14:00:52 UTC
Please describe the problem: The GNOME UI preferences are reflected in gconf, e.g. /desktop/gnome/interface/toolbar_detachable Since Gnumeric can now use gconf where available, it should obey the user's preferences. Steps to reproduce: 1. Go to GNOME's "Menu and Toolbar Preferences" 2. Disable the setting "Detachable toolbars" 3. Start Gnumeric, observe the toolbars Actual results: The toolbars are detachable despite the user (or administrator) preference. Expected results: The toolbars should no longer be detachable. Does this happen every time? Other information: I may have filed a bug about this before (back when Gnumeric did not use gconf) but I can't find it now. Hopefully the gconf support makes this easy, or at least within the grasp of someone familiar with Gnumeric's inner workings.
We don't have our own toolbar widget so I don't know why this isn't followed automatically. Do you know of any application that does follow this?
Applications like the gedit text editor, gthumb thumbnailer, evince document viewer etc. obey this preference "live". I guess they might all be special-cased, but it seems unlikely.
Likely or not... * gedit uses bonobo, i.e., another code base we do not want to touch * evince seems to use the experimental egg toolbar code I haven't check gthumb yet.
The toolbar preview in the "Menu and toolbar preferences" dialog look like the gnumeric toolbars, gthumbs toolbars look different namely the same as gedit.
It would be too much to expect for gnome to handle this automatically. The only program that I was able to find that uses the regular toolbar and handles the preference, coaster, watches the preference for changes and then disables the buttons.
OK, so I examined some of my own code, and I eventually figured this out. My source code doesn't mention Bonobo, but Bonobo does get linked into the running code, and it appears that the code which implements this preference is in the Bonobo code (for some reason which no doubt made sense to someone working on GNOME at that time). In the long term it would be nice to see this code moved into a GNOME library or even GTK+ rather than Bonobo, but meanwhile maybe Gnumeric can just read the gconf preference ? I guess the request for GNOME to be fixed deserves a new bug, but I don't have the energy. Apologies for time wasted by all involved tracking this down.
IIRC, the recommendation is that apps follow the GNOME toolbar layout prefs, but also provide their own layout pref to override it. Epiphany at least follows this model.
The toolbars in Gnumeric's "customize header and customize footer" dialog obey the general GNOME setting, without any special code for that. Why doesn't the main GNumeric toolbars?
It doesn't since we are forcing the style.
Created attachment 99409 [details] [review] patch to fix this bug
I am not sure about the patch from comment #10. The original reason we forced the style was that the toolbar widget forced all items to have the same size. The result was that we should only a few and the toolbar was useless. There was no point in showing a useless toolbar. The toolbar now allows individual sizes, but we are still showing only about half. To show the rest would require a screen several times as wide as mine. So to me it comes down to the question: do we want to follow Gnome policy in a case where it results in poor usability?
I guess the question is whether we know better than the user what the user wuld like? If the user selected "icons only", there is no difference between us forcing icon's only or the user selecting it. If the user selects "text beside icons", s/he only gets icons as before. If the user selects "text below icons", the user see lots of wasted real estate and lots of items slip into the extension menu. Personally I don't know why anybody would ever like that. If the user selects "text only" again many items slip into the extension menu. As far as I am concerned that was the users choice and I can imagine situations where icons are not reasonably recognizable by the user (for example some of our icons in "high contrast inverse" theme). So then text may be the best choice. Now ideally I would also like to have an override preference in gnumeric so that a user who uses icons and text in other apps could have just icons in gnumeric.
I should have mentioned that another time when text only could be useful without losing usability is when the toolbars are vertical.
@Andreas: a problem here is that 'text below icons' is the default mode of operation in GNOME. The 'override preference' you talk about is already present in Evince and Epiphany and is encourages by the HIG, IIRC.
Andreas #12 : Now that the toolbars have the extension drop downs the situation is not as dire as when we originally did this. However, it still seems as if the override should remain in place. Our toolbars are no where near the size of the average gnome app. Text beside degrades the utility of the toolbar so far that it is not useable. We could support yet another pref to 'force icon only toolbars' vs 'respect GNOME settings for toolbars', but that seems fairly obscure. I would not want to see that in the pref dialog, it would be a gconf only setting.
What's the current situation? Did my original problem get fixed and now we're haggling about something else in this bug ? Allow me to restate. There is a GNOME-wide interface setting /desktop/gnome/interface/toolbar_detachable It was previously not obeyed by Gnumeric, for an apparently endless list of reasons that I gave up arguing with. Is this pref now actually being obeyed? If not, why are people arguing about toolbar widths in my bug ?
Your bug got generalized. I don't think your bug got fixed. We could consider it "not gnumeric" since it isn't in gnumeric's code, but that would not be helpful. We are, I guess, still living in the hope that the gtk+ fix it. (Fat chance of that.)
sorry Nick, apparently I was looking at teh wrong GNOME Pref. THe version I currently am running has support for the setting you are talking about removed from its "appearance" control panel. (All the other parts of "menu/toolbar", have been moved there, so I believe that I am not just missung the menu/toolbar panel) Can anybody confirm that GNOME still expects that setting to be used _and_ has an appropriate gui tool to change it? Otherwise the original bug here has become mood.
You're correct, this option no longer appears in the Appearance GUI The Powers That Be decided (correctly in my opinion) that ordinary users don't want to accidentally drag big chunks of their UI around and drop them somewhere unexpected. So this is disabled by default and there is no longer any specific UI to enable it (you can of course re-enable it via Gconf) However Gnumeric's behaviour is currently exactly contrary to the GNOME setting, so deciding that the bug is "moot" at this point seems bizarre. If Gnumeric specifically does not want to obey GNOME's interface prefs, make that a bullet point, and close related bugs WONTFIX or NOTABUG or whatever. This would seem contrary to Gnumeric's stated goals, but that just means you need to change the goals, right?
Apparently this is not a gnome interface preference any more. I don't think poking around with gconf classifies as a preference considering that GNOME is a desktop. So as far as I am concerned this bug is moot. My sincere apologies to everybody involved for having touched this report. I should have known better.
“I don't think poking around with gconf classifies as a preference” Great, in that case we can now fix this problem by removing the unnecessary handlebox. Not an ideal solution, but an acceptable one until someone wants to do the extra work to implement the GConf pref. I will try to find time to supply a suitable patch in the next few weeks. It's basically just ripping out a lot of code I think.
Personally I don't think that removing a feature just because you don't like it will be accepted. If you don't want to detach the toolbars, just don't do it.
Nick: Andreas is quite correct. We will not be removing the feature. I'd accept a patch to disable the dock based on the gconf key but the priority to actually write it would be < epsilon.
Still doesn't look too difficult though my GConf is a bit rusty. Taking so that it stays on my radar. I'll re-assign when there's a patch.
Created attachment 106881 [details] [review] Patch against Gnumeric trunk to honour this UI pref
This patch is verified as working with my system, it obeys the gconf setting. On systems without GNOME it should have no effect, but I can't verify that. Note that when the handlebox is removed you do not lose the ability to have a toolbar in a non-standard position (e.g. left hand side), although the UI to change it goes away with the handlebox, the existing code in this patch gives you most of what's needed for someone else to add some UI for this if they fancy. I'm pretty content with this, so I am giving it you Jody, please commit this fix to trunk, and subsequently if deemed sufficiently low impact, merge to the stable branch as well.
/* annoyingly the backend agnostic config interface makes this impossible * so we do it ourselves */ I do not understand this. Why doesn't go_conf_get_bool (NULL, "key") do what you want?
Created attachment 106921 [details] [review] Fixed patch (thanks to Morten) Hmm, you're right - my reading of the code suggested that this API only worked on subkeys of /app/ which is fine for Gnumeric's own config settings but no good for my purposes. However testing your suggestion proves otherwise. I've supplied an updated patch which is now somewhat smaller and no longer includes this invalid criticism of the config interface.
Hmm... The default appears to be off: <schema> <key>/schemas/desktop/gnome/interface/toolbar_detachable</key> <applyto>/desktop/gnome/interface/toolbar_detachable</applyto> <owner>gnome</owner> <type>bool</type> [...] which is all good and fine, but the control center on my machine shows unset as-if things were actually _on_ -- the box is already checked!
This problem has been fixed in our software repository. The fix will go into the next software release. Thank you for your bug report.