Hmm, are you saying that the path and id should always match (ie. one is dotted and the other slashed but otherwise the same)? In that case why are they separate?

As far as I remember, this was needed when I first tested the gsettings support. Would things still work if the path was removed?

What is the alleged bug here?

The path should probably be identical to the id when you don't need them to be different. ;-) Actually, the path is only useful when a schema describes an instance of an object that you can duplicate to different paths (say: settings for a gnome-terminal profile).

The point is, all GNOME apps use org.gnome.$APP as path, except Gnumeric and maybe a few other ones. Using the same path would make things look a little tidier in dconf-editor (and using a correct prefix generally ensures there's no conflict, even if in Gnumeric's case that's not really an issue).

The general scheme is explained here: http://mail.gnome.org/archives/desktop-devel-list/2011-March/msg00151.html

AS was pointed out in some of the follow-ups to http://mail.gnome.org/archives/desktop-devel-list/2011-March/msg00151.html the patches there didn't even all follow the scheme given.

If we want to change the scheme again and since there is gnumeric.org shouln't the path and ids be /org/gnumeric/... and org.gnumeric.... respectively.

Gnome is likely to change its scheme again when they get around to have some proper gui to access and edit those settings, so I think this should really be a NOTABUG.

(In reply to comment #5)
> AS was pointed out in some of the follow-ups to
> http://mail.gnome.org/archives/desktop-devel-list/2011-March/msg00151.html the
> patches there didn't even all follow the scheme given.
> 
> If we want to change the scheme again and since there is gnumeric.org shouln't
> the path and ids be /org/gnumeric/... and org.gnumeric.... respectively.
> 
> Gnome is likely to change its scheme again when they get around to have some
> proper gui to access and edit those settings, so I think this should really be
> a NOTABUG.
Where did you read that? Isn't dconf-editor a proper GUI for this kind of thing? I don't see what kind of change could make the database saner. It's not really meant to be beautiful, it just needs to be consistent and predictable.

Well, there was:
> > No string changes, no code changes, no UI changes (except paths showed
> > in dconf-editor, but this is totally undocumented by now), and hard code
> > freeze exception yet pre-approved.

I read this as "no UI changes", which means to me that the dconf-editor is not a serious UI.

But I still haven't seen a reason of changing those paths.

I also see (this is in Ubuntu 11.10):
<schema path="/apps/gnome-system-tools/users/" id="org.gnome.system-tools.users">
<schema path="/system/locale/" id="org.gnome.system.locale">

(In reply to comment #7)
> Well, there was:
> > > No string changes, no code changes, no UI changes (except paths showed
> > > in dconf-editor, but this is totally undocumented by now), and hard code
> > > freeze exception yet pre-approved.
> 
> I read this as "no UI changes", which means to me that the dconf-editor is not
> a serious UI.
I think we don't really care since there's no documentation in the help for it, and no translations (which are the reasons for the string freeze). This doesn't mean we don't want it to be as clean as possible.

> But I still haven't seen a reason of changing those paths.
Of course, the incentive is relatively low... ;-)

> I also see (this is in Ubuntu 11.10):
> <schema path="/apps/gnome-system-tools/users/"
> id="org.gnome.system-tools.users">
I'm the maintainer of the g-s-t, and I know I did fix these paths. The problem is that you Ubuntu still uses 2.32, so they're never going to get the fix.

> <schema path="/system/locale/" id="org.gnome.system.locale">
Dunno about this one.

This problem has been fixed in the development version. The fix will be available in the next major software release. Thank you for your bug report.