GNOME Bugzilla – Bug 401030
ToolbarIconSize xsetting has no effect
Last modified: 2007-12-06 21:28:11 UTC
That bug has been described on https://launchpad.net/ubuntu/+source/gtk+2.0/+bug/81247 "When adding a gconf key for /desktop/gnome/interface/toolbar_icon_size nothing happens. Originally the key is empty and after setting a value nothing happens."
I don't think this is a gtk bug. That gconf key is defined as integer in the libgnome schemas, but gnome-settings-daemon tries to get the value as string.
I'd argue that what g-s-d does is actually correct, and the schema should be changed to make that setting a string. Granted, it would work as an int as well, but in all similar cases we seem to be using the strings for enums.
Created attachment 81325 [details] [review] proposed schema modification What I'm not quite sure about is whether the non-toolbar-related enum values should really be mentioned in the long description.
I don't think we can change the schemas type. What we should do instead is remove this key and add a new one with a different name, and make the settings daemon use that.
Would changing it really be a problem? If the gconf database contains the wrong type it simply means it won't work - just like it doesn't work now. Since it didn't work before either, are there any "API stability" promises we have to keep? If you really think it's a problem, any suggestions on what to call the new key?
How about translating GConf strings to XSettings int values in g-s-d ?
Matthias, our "problem" is that gconf has toolbar-icon-size as int currently... The easiest fix would of course be to just use the gconf int as XSetting. But since in similar cases we use the enum strings in gconf (and this is a bit more user-friendly (if it's allowed to use that term in connection with gconf-editor...)) I'd prefer using the strings in gconf. Apparently, both ints and strings work just fine as XSettings for this. We just need to decide how we want to solve it.
Actually, no, I see the problem now. GTK+ is happy with either numerical or string values, as long as they can be interpreted as values of the GtkIconSize enum. Changing the gconf key type to string and setting it to e.g. large-toolbar or dnd works nicely.
I agree that keeping ints in the gconf schema would be very confusing, since people are guaranteed to interpret them as pixel size, not as enum values. That happens with the C api all the time, too.
We could introduce a new "toolbar-icon-size-text" GConf key that will be favored over the "toolbar-icon-size" key if present and deprecate the old one. Having inappropriate semantics doesn't rectify breaking them. Instead, the traditional GTK+ route is the introduction of new API/semantics and deprecation of the old one.
Only we're not breaking anything. This has never ever worked. We mined through the entire SVN history...
You cannot change the gconf key from int to string _because it won't work_. Try the following: Install schema for /apps/test/key, type integer, default 0 Set key to 42 with gconf-editor. Install schema for /apps/test/key, type string $ gconftool-2 -T /apps/test/key Result: int
While that is true, I'm not sure whether it's really a problem. You're right that as long as you don't update (unset, set) the setting in gconf-editor the setting won't work (ie. you'll get the warning from g-s-d you get today, only the other way around). But as I said, that's no different from now. What's more interesting IMO is this: Install schema for /apps/test/key, type integer, default 0 Set key to 42 with gconf-editor. Install schema for /apps/test/key, type string $ gconftool-2 --type string --set /apps/test/key myString $ gconftool-2 -T /apps/test/key Result: string This is presumably what the settings dialog in cc will do eventually. Additionally, the toolbar_icon_size setting doesn't even specify a default, so 99% of the userbase won't have an int value set in the first place. Anyway, I don't really mind using a new key either if that's what you prefer. Let's just make a decision and move on.
Anybody around who can issue a final verdict?
Let's go with a new key.
Ok, anyone want to whip up a patch?
Created attachment 97510 [details] [review] rename key to toolbar_icons_size How about this, then?
What about the default value, what should it be? And the <long> description should document all possible values.
Created attachment 97739 [details] [review] schema mod with default and list of options Ok, we don't strictly need the default, but here it is. I've only mentioned small and large-toolbar in the long description since the other options don't really make sense for toolbars (while they do work fine from a technical pov).
Let's get this in for 2.21.
libgnome: 2007-12-06 Jens Granseuer <jensgr@gmx.net> * schemas/desktop_gnome_interface.schemas.in.in: replace the defunct toolbar_icon_size integer setting with a string setting and rename it so it doesn't conflict with the old one. Bug #401030. gnome-control-center: 2007-12-06 Jens Granseuer <jensgr@gmx.net> * gnome-settings-xsettings.c: use new setting from libgnome to make toolbar icon size setting work (bug #401030)