This introduces no functional changes; it only simplifies the code.
Instead of maintaining a separate pointer to the backend iff it’s a
`GDelayedSettingsBackend`, just test the `backend` pointer’s type.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #2426
Previously, the delay-apply status of the parent `GSettings` object
would be partially inherited: `settings->priv->backend` in the child
`GSettings` object would point to a `GDelayedSettingsBackend`, but
`settings->priv->delayed` would be `NULL`.
The expectation from https://bugzilla.gnome.org/show_bug.cgi?id=720891
was that `get_child()` would fully inherit delay-apply status.
So, ensure that `settings->priv->delayed` is correctly set to point to
the delayed backend when constructing any `GSettings`. Update the tests
to work again (presumably the inverted test was an oversight in the
original changes).
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Fixes: #2426
Also added (transfer full) or (transfer none) annotations while I was at it.
This is the result of checking each `Returns:` line in these files. I’ve
only considered nullability and transferability, and not other (potentially
missing or incorrect) annotations.
Helps: #2227
Update several links to allow the remote to use its configured default
branch name, rather than specifying `master` as the default branch name.
This will help avoid breakage if any of these projects rename their
default branch in the future.
Fix a few of the links where they were hitting redirects or had moved.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #2348
Using the generic marshaller has drawbacks beyond performance. One such
drawback is that it breaks the stack unwinding from the Linux kernel due
to having unsufficient data to walk past ffi_call_unixt64. That means that
performance profiling by application developers looks grouped among
seemingly unrelated code paths.
While we can't fix the kernel unwinding here, we can provide proper
c_marshallers and va_marshallers for objects within Gio so that
performance profiling of applications is more reliable.
Related to GNOME/Initiatives#10
If c_marshaller is provided during g_signal_new() registration, the
automatic va_marshaller will not be set. If we leave the c_marshaller as
NULL in the simple cases, both a c_marshaller and va_marshaller will be
set for us.
This is particularly helpful when dealing with stack traces from Linux
perf, which often cannot unwind the stack beyond the ffi_call_unix64
stack-frame on x86_64.
Related to GNOME/Initiatives#10
The caller cannot assume that the lists returned by various GSettings
functions (for example, lists of keys or schemas) will be returned in
any particular order.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Helps: #1781
I was trying to debug some memory leaks in the gsettings test.
Eventually, it seems that actually they’re caused by the
GMemorySettingsBackend being cached by GIOModule — so this commit makes
no functional changes. It should make the code and documentation a bit
clearer though.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
The docs sound like settings list is a thing, and
a ::children-changed signal exists. That is not the
case, and will never be the case at this point, so
stop pretending.
Closes: #1362
Recognise a new 'd' option in schema keys which gives a dictionary of
per-desktop default values. This dictionary is searched for the items
found in XDG_CURRENT_DESKTOP, in the order. If nothing matches (or if
the option is missing) then the default value is used as before.
This feature was requested by Alberts Muktupāvels and this patch is
based on an approach devised by them.
https://bugzilla.gnome.org/show_bug.cgi?id=746592
There are a couple of different ways (and soon one more) to access the
default value of a key. Clean up the various places that access this to
avoid duplication.
https://bugzilla.gnome.org/show_bug.cgi?id=746592
All those logging functions already add a newline to any message they
print, so there’s no need to add a trailing newline in the message
passed to them.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
Reviewed-by: nobody
When using g_settings_bind(), if a range binding triggers a range check
failure, g_settings_binding_property_changed() will return early, but it
won't cleanup properly causing some leaks. The binding will also still
be marked as 'running', which causes an assertion failure when trying to
free it:
"g_settings_binding_free: assertion failed: (!binding->running)"
Signed-off-by: Christophe Fergeau <cfergeau@redhat.com>
https://bugzilla.gnome.org/show_bug.cgi?id=794805
Looks like the author started typing one thing, then changed their mind
about how to phrase the sentence, and typed something else.
Signed-off-by: Philip Withnall <philip@tecnocode.co.uk>
On the warning/critical error handling paths for g_settings_set(), the
GVariant value was not ref-sunk, and the schema key was leaked. This
won’t affect code in production (unless it’s seriously buggy), but
eliminates some leaks from the error testing paths in the GSettings
tests.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
https://bugzilla.gnome.org/show_bug.cgi?id=779265
If we have an input parameter (or return value) we need to use (nullable).
However, if it is an (inout) or (out) parameter, (optional) is sufficient.
It looks like (nullable) could be used for everything according to the
Annotation documentation, but (optional) is more specific.
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.
https://bugzilla.gnome.org/show_bug.cgi?id=744678
Add a new section to the main GSettings documentation which documents
the best practices for integrating GSettings into an autoconf/automake
build system using the GLIB_GSETTINGS macro.
Some of this material was adapted from the migrating-gconf.xml guide.
https://bugzilla.gnome.org/show_bug.cgi?id=741788
The list of keys in a GSettings object depends entirely on the schema,
so it makes sense to expose this API there.
Move the implementation out of gsettings.c and into gsettingsschema.c,
replacing the earlier with a simple call to the new location.
We don't do the same for children because the children can change.
https://bugzilla.gnome.org/show_bug.cgi?id=740308
