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 669324 - API for getting 'reset' GSettings value
API for getting 'reset' GSettings value
Status: RESOLVED DUPLICATE of bug 668233
Product: glib
Classification: Platform
Component: gsettings
unspecified
Other All
: Normal enhancement
: ---
Assigned To: Allison Karlitskaya (desrt)
gtkdev
Depends on:
Blocks:
 
 
Reported: 2012-02-03 16:57 UTC by Allison Karlitskaya (desrt)
Modified: 2013-10-28 14:47 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Allison Karlitskaya (desrt) 2012-02-03 16:57:31 UTC
People often want to know the 'default' value of a key.  With schema defaults, translations, vendor overrides, translated vendor overrides and sysadmin lockdown, that word doesn't have a good meaning.

One concrete question that can be asked, however is "what value would this key have after I call g_settings_reset() on it?".

This has given rise to the semi-common pattern:

  s = g_settings_new ();
  g_settings_delay (s);
  g_settings_reset (s, "key");
  g_settings_get_string (s, "key");

which works rather well.

We could add a g_settings_get_reset_value() to prevent this song and dance.  The main problem there is that g_settings_get() has quite a lot of variations and we'd probably not want to have:

 g_settings_get_reset()
 g_settings_get_reset_value()
 g_settings_get_reset_string()
 ...

So maybe it's not worth it at all.  If we only add one or two of those calls (maybe the GVariant* and the varargs version) then most people (particularly from bindings) may actually find it *easier* to just do the 'delay' trick above...
Comment 1 Didier Roche 2012-02-07 09:09:07 UTC
I think you are making a great point on the multiple variant of _get() needed in that case.

As a happy user of the "delay" trick here, I think it will simply make more sense to make it the code snippet clearer on the documentation as a way to get the possiblity resetted value for a key. What do you think?
Comment 2 Luca Ferretti 2012-05-30 10:52:18 UTC
Partially related, a little issue I had with `gsettings reset` (and reset-recursively, of course) command was: how could I "reset" the key to vendor override? Currently it seems able to restore only schema default values.
Stuff for a separate bug?
Comment 3 Allison Karlitskaya (desrt) 2012-05-30 12:37:08 UTC
Luca: this is a well-known bug with dconf-editor.  The key really is reset to the vendor override.  dconf-editor is showing the wrong value.
Comment 4 Allison Karlitskaya (desrt) 2013-10-28 14:47:34 UTC
Patches in bug 668233.

*** This bug has been marked as a duplicate of bug 668233 ***