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.
The delayed backend implments "user value" by returning anything that's
in the changeset (incuding an explicit NULL) or chaining up otherwise.
We will use this for g_settings_get_user_value().
https://bugzilla.gnome.org/show_bug.cgi?id=668233
As it turns out, we have examples of internal functions called
type_name_get_private() in the wild (especially among older libraries),
so we need to use a name for the per-instance private data getter
function that hopefully won't conflict with anything.
First, correct a rather dubious case of accessing a GSettingsSchemaKey
after clearing it. This was technically okay because only the key name
was accessed (and it is not owned by the struct) but it looks very
wrong.
Second, have g_settings_backend_write() sink the passed in GVariant*.
Not all backends get this right, and I'm starting to like the pattern of
virtual function wrappers being responsible for sinking the parameters
that they are documented as consuming.
Add _g_io_module_get_default(), which implements the
figure-out-the-best-available-module-that-is-actually-usable logic,
and use that to simplify g_proxy_resolver_get_default(),
g_settings_backend_get_default(), g_tls_backend_get_default(), and
g_vfs_get_default().
https://bugzilla.gnome.org/show_bug.cgi?id=620932
When g_settings_apply() is called on a delayed settings backend and
there is a D-Bus error when communicating with dconf-service, recent
versions of the dconf GSettingsBackend call a function in GLib that
improperly delivered the signal directly instead of using
g_main_context_invoke().
This patch fixes this function to route in the same way as the others so
that the signal is dispatched in the proper GMainContext.
To help cross compilation, don't use glib-genmarshal in our
build. This is easy now that we have g_cclosure_marshal_generic().
In gobject/, add gmarshal.[ch] to git (making the existing entry
points stubs).
In gio/, simply switch to using g_cclosure_marshal_generic().
https://bugzilla.gnome.org/show_bug.cgi?id=652168
If GSettings is uninitialised then g_settings_sync() should very
obviously just return right away (rather than attempting to initialise
GSettings first).
For GSettings.
Use the functionality introduced in the last commit to simplify our
notify dispatching and increase the safety of doing so (by ensuring that
the context is acquired in the current thread for the duration of the
dispatch).
This closes bugs #623400 and #629849.
- hold a lock while accessing the tree of delayed values
- use weak reference counts with the owner object to avoid doing
g_object_notify on a dead object
- dispatch the "has-unapplied" notify to the proper main context
This commit fixes up a few race conditions in the GSettingsBackend, mostly with
respect to change notifications occuring at the same time as the last reference
count on a GSettings is dropped. With GDBus feeding us our incoming signals in
a separate thread, this is something that could easily happen.
- used in some places as a move-along-as-we-go pointer
- used in other places as a pointer to the fixed base of an array
Switch all users to the first style to avoid a crasher.
