GNOME Bugzilla – Bug 668233
Unable to determine if a key is set to the default / what the default value is
Last modified: 2013-10-28 18:28:42 UTC
There is no API to determine if a key is set to the default / what the default value is. Perhaps: GVariant *g_settings_get_default (GSettings *settings, const gchar *key); gboolean g_settings_is_default (GSettings *settings, const gchar *key);
the reason that this API isn't exposed is because 'default' has a lot of meanings. default per the schema? default as per the sysadmin default? how about lockdown? fwiw, there is a bit of a well-known trick: create a GSettings, delay it, reset the keys and query their values -- you will get the value that the key has as if it were reset which is some sort of reasonable definition of 'default', i guess. we should definitely be able to expose the default-per-schema value via the new schema/schemasource APIs.
what I really need to know is "g_settings_is_set" - i.e. is there a value that has been set at some point and stored in the backend.
And I guess g_settings_get_default () would get the value if the key was unset.
The current API this relates to is g_settings_reset. i.e. g_settings_is_set() tests if g_settings_reset() would do anything, g_settings_get_default() returns the value that will be returned after g_settings_reset() is called.
This can't be solved without changing the backend API. The current API allows us to ask two questions: 1) What is the value? 2) What is the default value? We can't just compare because it could be that the user has explicitly set the default value as their preference.
*** Bug 697130 has been marked as a duplicate of this bug. ***
There are use cases for this. There was somebody on IRC complaining that he could revert but that he couldn't tell the user what it was going to be reverted to which is quite dangerous.
FWIW I'd like to use this API in tweak-tool
Created attachment 258239 [details] [review] GSettingsBackend: add read_user_value() API This will get the 'user' value from the database (ie: the one that the user has control over). Provide a default implementation that chains to ->read(). That will work for all of our internal backends which don't have a concept of layering or lockdown. We will use this for g_settings_get_user_value().
Created attachment 258240 [details] [review] GSettings: small internal refactor Add two boolean parameters to our internal getter utility function in anticipation of the coming addition of g_settings_get_user_value() and g_settings_get_default_value() APIs.
Created attachment 258241 [details] [review] GSettings: add getters for user/default value Add two new APIs: g_settings_get_user_value() and g_settings_get_default_value(). Together, these should allow the inspection of all interesting cases of "is this key set?" and "what would happen if I reset this key?"
Review of attachment 258239 [details] [review]: Ok.
Review of attachment 258240 [details] [review]: Ok.
Review of attachment 258241 [details] [review]: Looks good to me. How will this interact with delayed settings?
Created attachment 258242 [details] [review] GSettings: implement _read_user_value() Implement g_settings_backend_read_user_value() in DConfSettingsBackend. This will help us support g_settings_get_user_value() properly. We add a new engine API to support this as well. It takes a read_through queue, even though we don't bother using that from DConfSettingsBackend.
> How will this interact with delayed settings? hm. Poorly. I think I need to implement the new vfunc on the backend and pass it through in the case that it's not set on the delayed object itself... Will post a new patch.
*** Bug 669324 has been marked as a duplicate of this bug. ***
Attachment 258239 [details] pushed as 84a6e65 - GSettingsBackend: add read_user_value() API Attachment 258240 [details] pushed as 2d06dbe - GSettings: small internal refactor Attachment 258241 [details] pushed as bebdfb8 - GSettings: add getters for user/default value
Attachment 258242 [details] pushed as 863fa5c - GSettings: implement _read_user_value()
*** Bug 705463 has been marked as a duplicate of this bug. ***