After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 664243 - Incorrect gsettings key schemas
Incorrect gsettings key schemas
Status: RESOLVED FIXED
Product: Gnumeric
Classification: Applications
Component: General
1.10.x
Other Linux
: Normal normal
: ---
Assigned To: Jody Goldberg
Jody Goldberg
Depends on:
Blocks:
 
 
Reported: 2011-11-17 03:41 UTC by Jean-François Fortin Tam
Modified: 2011-11-18 19:18 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Jean-François Fortin Tam 2011-11-17 03:41:53 UTC
grep "path=\"/apps" /usr/share/glib-2.0/schemas/*

reveals that there are a bunch of keys located in /usr/share/glib-2.0/schemas/org.gnome.gnumeric.plugin.gschema.xml that have a schema path="/apps/gnumeric/plugin/* and an id="org.gnome.gnumeric.plugin.*

Could it be a mistake?
Comment 1 Andreas J. Guelzow 2011-11-17 05:16:13 UTC
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?
Comment 2 Jean Bréfort 2011-11-17 09:41:32 UTC
As far as I remember, this was needed when I first tested the gsettings support. Would things still work if the path was removed?
Comment 3 Morten Welinder 2011-11-17 13:59:30 UTC
What is the alleged bug here?
Comment 4 Milan Bouchet-Valat 2011-11-17 17:00:34 UTC
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
Comment 5 Andreas J. Guelzow 2011-11-17 17:29:09 UTC
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.
Comment 6 Milan Bouchet-Valat 2011-11-17 17:43:43 UTC
(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.
Comment 7 Andreas J. Guelzow 2011-11-17 19:28:03 UTC
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">
Comment 8 Milan Bouchet-Valat 2011-11-18 09:49:25 UTC
(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.
Comment 9 Jean Bréfort 2011-11-18 19:18:35 UTC
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.