GNOME Bugzilla – Bug 539840
Gtk/Modules XSETTINGS property sucks
Last modified: 2008-09-12 19:22:55 UTC
The "Gtk/Modules" XSETTING sucks as it is implemented now: it is bound to a gconf key /desktop/gnome/gtk-modules, which isn't defined in any schema file and sits directly beneath /desktop/gnome which is ugly. Also, this key is kind of useless for modules that would like to be loaded for all gnome sessions such as the a11y modules or libcanberra-gtk-module, because they'd fight for a single string. Also, installing a module for all sessions cannot just be done by sticking a file somewhere because some logic is needed to concatenate the old value of this setting with the new module string, for all active sessions. So, instead of making this gconf key official and adding it to the schema I'd suggest killing it and replacing it by a subdir /desktop/gnome/gtk-modules/ in which each module that would like to be loaded can create a subdir, similar to /desktop/gnome/gtk-modules/libcanberra-gtk-module/enabled=true. That way, different programs wouldn't need to fight for that single string and could easily just stick a file somewhere to be loaded from then on.
Isn't xsettings supposed to be cross desktop? Isn't gconf or xsettings supposed to be dynamically changeable (and reflected by the clients)? Why a .ini would be too complicated? Why not have multiple module.ini if necessary? (my stupid questions, to annoy Lennart)
(In reply to comment #1) > Isn't xsettings supposed to be cross desktop? Yes, absolutely. > Isn't gconf or xsettings supposed to be dynamically changeable (and reflected > by the clients)? XSETTINGS is equally dynamic. Changes in XSETTINGS like the gtk theme changes are reflected instantly in all gtk apps. And the gtk-modules GtkSetting comes directly from XSETTINGS and is properly handled by Gtk (i.e. if a new module appears in that setting it is loaded). > Why a .ini would be too complicated? Why not have multiple module.ini if > necessary? the way gtk is configured is through GtkSettings. It's dynamic and cross-desktop and everything. Remember that gtk doesn't link against gconf!
I don't know if anybody already uses the gconf setting, but I suppose it's rather unlikely. (In reply to comment #0) > ... a subdir /desktop/gnome/gtk-modules/ in > which each module that would like to be loaded can create a subdir, similar to > /desktop/gnome/gtk-modules/libcanberra-gtk-module/enabled=true Do you expect modules to put other settings there as well?
(In reply to comment #3) > I don't know if anybody already uses the gconf setting, but I suppose it's > rather unlikely. > > (In reply to comment #0) > > ... a subdir /desktop/gnome/gtk-modules/ in > > which each module that would like to be loaded can create a subdir, similar to > > /desktop/gnome/gtk-modules/libcanberra-gtk-module/enabled=true > > Do you expect modules to put other settings there as well? Hmm, dunno. My own module (libcanberra-gtk-module) certainly wouldn't. Dunno about others. The only ones that come to my mind here are the a11y modules, and I don't think there is any need for them to have additional settings.
/desktop/gnome/gtk-modules/libcanberra-gtk-module/enabled=true Sounds like a good idea in principle, but isn't this somewhat redundant with the preexisting settings for some modules such as: /desktop/gnome/interface/accessibility /desktop/gnome/sound/event_sounds ?
(In reply to comment #5) > /desktop/gnome/gtk-modules/libcanberra-gtk-module/enabled=true > > Sounds like a good idea in principle, but isn't this somewhat redundant with > the preexisting settings for some modules such as: > > /desktop/gnome/interface/accessibility > /desktop/gnome/sound/event_sounds Sure it would. But the idea of the original suggestion is that g-s-d can just go through those dirs without knowing anything about the modules in question. It would just enumerate the dirs, check for "enabled" and load the modile in question if that setting is true. i.e. we could get rid of the hardcoded checks for very specific gconf keys, like the two you listed.
I worry a bit about having redundant settings because you suddenly need to check two checkboxes to make a feature work. I'm pretty sure we'll get (hard to figure out) bug reports due to things not working as expected when setting e.g. event_sounds to true. Wouldn't it be better to just let g-s-d know about the few settings where this is relevant and have it adjust the gtk-modules xsetting accordingly? GtkModules aren't that common, are they?
> Wouldn't it be better to just let g-s-d know about the few settings where this > is relevant and have it adjust the gtk-modules xsetting accordingly? GtkModules > aren't that common, are they? In practise, it probably boils down to a11y + sounds. So, yes. I think handling this non-generically in g-s-d would be the better approach.
My /usr/lib64/gtk-2.0/modules/ has mre than a11y and libcanberra. No idea what that is, but it's there...
Oh, right. bug-buddy too.
What is gnomebreakpad? And what is ferret?
gnomebreakpad -> bug-buddy ferret -> a11y
It would be interesting to find out which Fedora packages drop files in /usr/lib64/gtk-2.0/modules/. Unfortunately my yum/rpm-fu isn't good enough for querying information like that.
Hmm, with google codesearch I found the following code was implemented using Gtk modules: - Tim Janik's Gtk Event Recorder (gerd) - some GPE input module ("libgtkinput") and another one ("libgtkstylus"), and a third one ("libpresslong") - gtk on-screen keyboard "glok" - "gtkinspector" - "gnome-dashboard" - "gtk-speak" - some gnome "spytime" benchmarking tool - some kiosk-mode related "onebutton" module - some "gtkamber" module that makes menus translucent Dunno how comprehensive this list is, and how much of it is total crack. But I think for some of these modules it would make sense to have them in a generic gconf property.
none of that has any mainstream relevance, as far as I can tell.
(In reply to comment #15) > none of that has any mainstream relevance, as far as I can tell. That might be true. But maybe that's exactly the reason why it should be possible to install these modules easily by just dropping a gconf schema file somewhere?
Not if the potential for bogus bug reports is bigger than the assumed user base.
Created attachment 115726 [details] [review] proposed patch Patch only handles libcanberra at this point. No idea what to do for a11y.
What about the following? /desktop/gnome/gtk-modules/gnomebreakpad/enabled=true /desktop/gnome/gtk-modules/libcanberra-gtk-module/condition=/desktop/gnome/sound/event_sounds Please don't shoot me for heresy or something ;)
The point sort of was not to make it generic. Matthias, Lennart, can you live with the solution in the patch?
@Jens Why not make it generic? gnome-session has long suffered because of such specific cases (see replacing session startup with generic desktop files).
Read the backlog. Admittedly, making the keys depend on other keys, while somewhat redundant, renders most of my concerns moot. I don't think the problem is anywhere near what was up with gnome-session, though.
Couldn't this be done via .desktop files? We already have this for autostart in gnome-session, and we can enable/disable the modules by using the hidden key in .desktop files. Also, would we need a GUI to enable/disable the modules?
(In reply to comment #23) > Couldn't this be done via .desktop files? We already have this for autostart in > gnome-session, and we can enable/disable the modules by using the hidden key in > .desktop files. Sure we could. Desktop files are nothing but glorified config files after all. I don't see why we'd want to, though. What does loading gtk modules have to do with starting applications? Apart from the "hidden" property (which I'd already consider a kludge in this context) I don't even see a lot that could be reused from the desktop spec. > Also, would we need a GUI to enable/disable the modules? No. a11y plugin is loaded when a11y is enabled, bug-buddy is always enabled (?), libcanberra is enabled when desktop sounds are enabled. If you really want to fine-tune those settings, use gconf.
well, it makes it easier for apps to just put a .desktop (or whatever format) file in a known place than to deal with a set of GConf keys. The same for users, easier to edit a .desktop file than to find and set the apropriate GConf keys.
Desktop files are not the solution to every problem, and this is not for users to tweak directly. I don't think we need to make this more complicated than necessary. I'm still in favour of a single location in gconf, where modules can drop a key. That key-redirection proposal strikes me as too complicated and error-prone.
Matthias: Key redirection proposal is there exactly to reduce the error rate. We don't want to force applications to write or - worse - read the same preference from 2 or more keys in gconf. What if you want to determine if - for example - sounds are enabled? Do you check the actual gconf switch used by gnome-control-center or do you check the libcanberra key in gtk-modules? What if one is true and the other is false? You just learn to ignore one of them. If two applications pick different places to ignore, we get inconsistent behavior.
Created attachment 118227 [details] [review] another attempt Here's another cut. This version supports putting keys below /apps/gnome_settings_daemon/gtk-modules/. The keys is exptected to be the name of the plugin, the value can either be boolean (enabled/disabled) or a the name of another gconf key of type bool, e.g. gconftool-2 --set --type bool /apps/gnome_settings_daemon/gtk-modules/canberra-gtk true or gconftool-2 --set --type string /apps/gnome_settings_daemon/gtk-modules/canberra-gtk /desktop/gnome/sound/event_sounds One issue is that GConf doesn't really allow us to monitor arbitrary keys ("Added directories may not overlap"). This means that when using the string version, changes to the key referred to are not currently monitored at runtime and thus, changes don't get applied on the fly. I'm not sure if that is fixable.
The monitoring issue is a bit of a bummer, since the most likely reason to use the indirection is that there is a preexisting key for which we have ui to set it at runtime... Anyway, the patch certainly works for what it does, and is certainly good enough to support a11y, bug-buddy and libcanberra. +1 from me.
(In reply to comment #29) > The monitoring issue is a bit of a bummer, since the most likely reason to use > the indirection is that there is a preexisting key for which we have ui to set > it at runtime... Yah. I've disabled that part in the commit for now.
After IRC discussion, reenabled key redirection.