GNOME Bugzilla – Bug 765965
move DConfChangeset into glib as GSettingsBackendChangeset
Last modified: 2018-02-02 10:48:22 UTC
There's no denying the fact that GSettingsBackend is effectively an abstraction of dconf. dconf contains a fantastically useful data structure called DConfChangeset that models the state of a dconf database, or a set of changes to a dconf database. In reality, this data structure also models state of GSettings backends and changes to them as well. Let's merge the code into GIO. We can drop the GTree-based interface for changesets and move over to using the changeset type natively. We can also use it to help us with implementation of the delayed and memory backends. The reason we're doing this here is for another backend that will be a very heavy user of GSettingsBackendChangeset: the container settings backend.
Some review from the branch: Want more docs/comments on GSettingsBackendReadFlags and for the new vfuncs in gsettingsbackend g_settings_backend_changeset_new() typo: - * contents are the database are what you would have if you applied the + * contents of the database are what you would have if you applied the g_settings_backend_changeset_is_similar_to: * Strictly speaking, a write resettings all of "/a/" after a write * containing "/a/b" could cause the later to be removed from the queue, * but this situation is difficult to detect and is expected to be * extremely rare. Its not clear what you mean here. A clear of /a/ would not be "similar to" a write of /a/b, so how is this related to this function? g_settings_backend_changeset_seal() typo: - * value of that key) or %NULL (to reset a reset). + * value of that key) or %NULL (to request a reset). g_settings_backend_changeset_change (): The docs should mention that the the "changes" argument must be sealed (it return_if_fail on that. Actually, why is this needed? It will be sealed automatically otherwise? With the new g_settings_backend_is_*, can't the gsettingsbackend.c is_* local funcs just be g_return_val_if_fail (g_setttings_backend_is_*(), FALSE); g_settings_backend_changeset_applied() claims Since 2.26 which seems wrong g_settings_backend_changeset_applied() - This doesn't seem to do anything with key resets, it just emits keys_changed for all the reset:ed dirs. Is that really right? Shouldn't each reset in the changeset emit a path_changed? g_settings_backend_changeset_serialise() - this uses "serialise", but other apis in glib like g_icon_serialize uses "serialize". Also serialize seems more popular according to google. Also, its not clear how serialise can be used, as the format is unspecified. Can we at least define if it is stable over time or not? I.e. can i store it in a file?
*** Bug 759129 has been marked as a duplicate of this bug. ***
(Probably this branch: https://git.gnome.org/browse/glib/log/?h=wip/gsettingsbackendchangeset)
This was meant to be used for the GSettings-based plans to proxy dconf, and those have completely fallen through at this point (in favour of a dconf-based solution), so let's WONTFIX this.