A question has been bugging me for some time: what’s the reasoning behind the dconf hierarchy/naming scheme as can be seen in dconf-editor?
org.gnome.*, org.gtk.*, ca.desrt.*, org.freedesktop.* … okay, I get that those are meant to look like reversed URLs, that part makes sense… but not as much when you have desktop.gnome.*, desktop.gstreamer.*, apps.*, a11y.*
Here comes the fun part:
- Why is gnome-shell in “apps” but not in “org.gnome” like most of the other core apps? …oh wait yes it is also there, but this time it’s named “shell”!
- Why are “proxy”, “smb”, “webkitgtk” and such present in “system” whereas “power-manager”, “packagekit”, “login-screen”, “bluetooth”, “screensaver” are not?
- org.gnome.desktop.a11y exists (just to complement the toplevel “a11y” tree, you know), just as org.gnome.desktop exists to complement desktop.gnome
- Etc.
Where is the consistency and how are users and developers expected to know where to find what? I must be missing something (except aspirin)… please enlighten me.
The fact that you would need a search interface is a bad sign. Just try to find how to reset your font settings in less than two minutes and twenty clicks, I dare you.
Business management consultant, branding strategist, free & open-source software contributor and experienced community manager. Has unlimited hi-HP potions to keep teammates alive.
You can check out my main website, find me on Twitter or Mastodon or subscribe to my YouTube channel.
You can check out my main website, find me on Twitter or Mastodon or subscribe to my YouTube channel.
Latest posts by Jeff (see all)
Comments
15 responses to “Naming schemes”
I agree with you. Have you filed a bug?
Against what, every product in gnome bugzilla? 😉
Or if it’s a “we need clear HIG-like guidelines”, what should it be filed on?
The story is that we didn’t impose a naming convention when GSettings was introduced, and we ended up with a few apps not using the org.gnome scheme. This is explained for example here: http://mail.gnome.org/archives/desktop-devel-list/2011-March/msg00151.html
But it seems to be fixed now. This returns only two results on Fedora 15:
grep “path=\”/apps” /usr/share/glib-2.0/schemas/*
So what you see are probably left-overs from 2.32 or development versions. Other modules indeed need bug reports.
Most of that are just leftovers from older releases, so I guess the real problem here is that dconf doesn’t clean up old values after the schemas are around. And as all this is now stored in one single file all you can do is to remove ~/.config/dconf/user
dconf is just idiotic in general. Storing configuration in binary files? WTF! Its fine to use them as a cache but using a single binary file as the config storage for *all* your apps is just rediculous.
@foo, if you want to moan about dconf, at least try to make up a remotely valid technical argument, instead of ranting on things you obviously don’t know anything about. Storing the configuration in a single binary file is one of the good things that dconf does. There are plenty of things to complain about, but that isn’t one of them.
And, @nekohayo, some of the non-org/com/whatever values may also be poorly migrated values from former gconf settings values.
Rodney, what would be the next step to take towards cleaning up all this?
I agree that the organization is fairly messy – and everything under org.gnome doesn’t really help, since it’s mostly only GNOME stuff that uses dconf anyway, you just moved the messiness into a sub-tree. The author’s second point is entirely valid. I know the reason for it – lots of those things are now modules of gnome-settings-daemon – but that doesn’t make it not silly.
This is made *especially* fun by the fact that dconf-editor still has no search function. Gneef.
@nekohayo, not entirely sure exactly. You’re not even delving into the part where it gets really nasty in your post, either. GSettings API will abort if there is no schema. This means any settings left around in there, where the schema no longer exists, could result in applications appearing to crash, if they ever try to access any of those settings that have moved.
And I think the “official” answer is that dconf-editor is not part of GNOME, and users will never actually see those strings anyway, so it doesn’t matter how ugly/disorganized they really are in the end. The reverse domain stuff as a means to try and make settings unique, is also complete nonsense. Not sure how you could go about getting it properly cleaned up exactly.
Rodney, there’s no risk of crash. If settings are left in the dconf database with no schemas, it means the apps don’t use them already, or they would have crashed. Removing schemas is a problem, not settings: in the worst case, removing settings amounts to using the default value from the schema. (Though I’m not aware of any way to remove values with no schema except removing the whole dconf database. Support for such cleaning should probably be added.)
IMHO the reverse domain names make sense. Of course, most programs will end in org.gnome and org.freedesktop, but inside these, every app should have it’s separate tree, which is relatively clean and easy to find. That’s the best way to be sure no conflicts appear, and it’s mostly clean already except for old settings left without schemas on old installs. What would you propose instead?
@Milan: interesting, this is what happens on my Fedora 15 laptop (haven’t tried on the Fedora 16 one yet):
$ grep “path=\”/apps” /usr/share/glib-2.0/schemas/*|wc -l
32
$ grep “path=\”/org/gnome” /usr/share/glib-2.0/schemas/*|wc -l
186
@nekohayo: Weird. What are the matching files?
Ah I see, it was mostly gnumeric’s fault (it had a bunch of keys there).
The rest was seahorse, telepathy-logger and gnomine.
How should one delete/reset all the keys that don’t have schemas, so I can look at what it looks like? And could it be an idea that the settings daemon automatically clears entries without schemas that have not been used in a while?
I think you should file a bug against glib to ask for such a feature in the gsettings tool. dconf-editor could probably do this too. But automating the cleaning might really harm if for some reasons a few schemas are temporarily missing (upgrades, broken installs, weird plugins…).
Also, reporting a bug in Gnumeric would be good, if they’re not aware of the problem.
Gnumeric bug already filed at https://bugzilla.gnome.org/show_bug.cgi?id=664243 but the devs seem puzzled as to if it is a bug or not… Perhaps you could comment on the issue of path vs id etc.?
Filed the feature request to cleanup the tree in https://bugzilla.gnome.org/show_bug.cgi?id=664278