GNOME Bugzilla – Bug 744678
Unable to delete relocatable schemas
Last modified: 2018-05-24 17:27:27 UTC
Whilst relocatable schemas offer huge advantages, the single disadvantage in their use is the inability to remove them. In my instance, I intend to employ relocatable schemas in much the same fashion as was seen in gnome-panel, but within Budgie Panel. Each applet gets a schema, and then we add its key to a list of current applets. However, we need to delete those when we remove one, because I'm freakishly OCD and don't want to leave old schemas lying around. Bait: We resort to ini files right now. Ini files are evil and must die =)
Created attachment 297240 [details] [review] GSettings: make _get_default_backend() public This is now part of the guaranteed-stable API of GSettings.
Created attachment 297241 [details] [review] GSettingsBackend: add reset_path() API This fills a long-standing hole in the GSettings API: the ability to clean up after relocatable schemas that no longer exist. dconf already happens to support this without further changes. It turns out that the GKeyFile backend also contains code to handle this case -- it was just dead before, but now it's working. The "null" backend doesn't need support, and we throw a critical if anyone tries to use it with the "delayed" backend. That's reasonable, since there is no way to directly gain access to a delayed backend, other than by stealing it out of an existing settings object. Support still needs to be added to the Windows registry and nextstep backends.
I already dislike how ugly this got (but I attach it here just in case we want to keep it). New approach coming soon.
Created attachment 297609 [details] [review] DConfChangeset: implement dir resets properly If a dir is reset against a DConfChangeset then the result ought to be that all keys under that dir read as NULL (until such a time as they are set to a new value). This is consistent with the (existing) behaviour that a key will read as NULL if it, itself, was reset. In order to make that efficient, we create a separate GHashTable to serve as a cache of all of the directories that have been reset and iterate it whenever we do a key lookup that doesn't have a direct hit. We update (and expand) the test case to reflect this new reality -- the tests actually had a case that relied on the inconsistent behaviour.
Created attachment 297610 [details] [review] g_settings_reset(): add precondition checks Ensure that @key is non-%NULL on g_settings_reset(). It turns out that using g_settings_reset() with %NULL key (although invalid as per the API documentation and not possible via bindings) accidentally produces the same effect as the _reset_all() API that we are about to add. Add the standard precondition checks to prevent that from happening.
Any chance of this landing this cycle?
Comment on attachment 297609 [details] [review] DConfChangeset: implement dir resets properly Attachment 297609 [details] pushed as c6423fa - DConfChangeset: implement dir resets properly
Comment on attachment 297610 [details] [review] g_settings_reset(): add precondition checks Attachment 297610 [details] pushed as ca03753 - g_settings_reset(): add precondition checks
Hello, any progress in adding reset_path() api?
Will this be implemented?
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/glib/issues/993.