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
g_settings_has_signal_handlers() checks whether any of the signals has
pending handlers. However, g_signal_has_handler_pending() matches on
exact detail, even when passing 0. Subscribing to one of GSettings'
signals with a detail will fail this check and never connect to the
backend.
Fix this by calling has_handler_pending() with the key as detail as
well.
https://bugzilla.gnome.org/show_bug.cgi?id=740848
GSettings objects begin watching for changes as soon as they are created
in order that they can emit the "changed" signal.
In the case of dconf, if we want to be able to emit the changed signal,
we need to go on the bus and add some match rules. This requires
creating the dconf helper thread and also requires initialising GDBus
(which creates another thread).
Some users of GSettings are never interested in the "changed" signal.
One of these users is the glib-networking code that gets run every time
a new network connection is created.
Some users are reporting that they are annoyed that simply establishing
a network connection would spawn two extra threads and create a D-Bus
connection.
In order to avoid doing unnecessary work for these simple uses, delay
the subscription until we know that we will actually need to do it.
We do this in a simple way, using a simple argument: in order for the
user to care that a value changed then they must have:
1) watched for a change signal; and then
2) actually read a value
If the user didn't actually read a value then they cannot possibly be
interested in if the value changed or not (since they never knew the old
value to begin with and therefore would be unable to observe that it
ever changed, since they have nothing to compare the new value with).
This really is a behaviour change, however, and it does impact at least
one user: the 'monitor' functionality of the GSettings commandline tool,
which is interested in reporting changes without ever having known the
original values. We add a workaround to the commandline tool in order
to ensure that it continues to function properly.
It's also possible to argue that it is completely valid to have read a
value and _then_ established a change signal connection under the
(correct) assumption that it would not have been possible to miss a
change signal by virtue of not having returned to the mainloop.
Although this argument is true, this pattern is extremely non-idiomatic,
and the problem is easily avoided by doing things in the usual order.
We never really talked about change notification in the overview
documentation for GSettings, so it seems like now is a good time to add
some discussion, including the new rules for when one can expect change
signals to be emitted.
https://bugzilla.gnome.org/show_bug.cgi?id=733791
This property has been deprecated for three years after only having
existed for one. We've wanted to reuse the name for all that time, so
let's try to actually remove it now and see if we can get away with it.
https://bugzilla.gnome.org/show_bug.cgi?id=732102
Change the order of the arguments on the (internal) keys_changed callback in
GSettingsListenerVTable.
This means that all functions in the table now fit the following signature:
void (* f) (GObject *target,
GSettingsBackend *backend,
const gchar *name_or_path,
gpointer origin_tag,
const gchar * const *names);
allowing the possibility of arguments ignored at the end.
This allows us to simplify our dispatch-to-thread code in GSettingsBackend,
making it a bit less generic.
So far, this should be a straight refactor.
https://bugzilla.gnome.org/show_bug.cgi?id=710367
Since all element markup is now gone from the doc comments,
we can turn off the gtk-doc sgml mode, which means that from
now on, docbook markup is no longer allowed in doc comments.
To make this possible, we have to replace all remaining
entities in doc comments by their replacement text, & -> &
and so on.
Part of the purpose of g_settings_get_child() was that it could be used
after you delay() a GSettings object, and then apply() all of the
settings together. In order for that to work, we need to share the
backend.
https://bugzilla.gnome.org/show_bug.cgi?id=720891
Allow only format strings that copy all values (i.e, don't contain '&'),
as the returned pointers might become invalid in some rare cases.
Since this is technically an API break, this patch only prints a
critical when a faulty format string is detected, but still fetches the
values.
https://bugzilla.gnome.org/show_bug.cgi?id=719979
Add g_settings_schema_has_key() and _get_range(), _range_check(),
_get_value_type(), _get_default_value() methods on GSettingsSchemaKey.
Deprecate the equivalent APIs on GSettings.
https://bugzilla.gnome.org/show_bug.cgi?id=683017
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?"
https://bugzilla.gnome.org/show_bug.cgi?id=668233
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.
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.
Back in the far-off twentieth century, it was normal on unix
workstations for U+0060 GRAVE ACCENT to be drawn as "‛" and for U+0027
APOSTROPHE to be drawn as "’". This led to the convention of using
them as poor-man's ‛smart quotes’ in ASCII-only text.
However, "'" is now universally drawn as a vertical line, and "`" at a
45-degree angle, making them an `odd couple' when used together.
Unfortunately, there are lots of very old strings in glib, and also
lots of new strings in which people have kept up the old tradition,
perhaps entirely unaware that it used to not look stupid.
Fix this by just using 'dumb quotes' everywhere.
https://bugzilla.gnome.org/show_bug.cgi?id=700746
We were using the user-passed value of the @property argument for
several purposes in g_settings_bind(): error messages, binding
uniqueness (ie: one-binding-per-property-per-object) and most
importantly, connecting to the detailed notify:: signal.
The user may pass a string like "property_name" when the property's
canonical name is "property-name". g_object_class_find_property() will
find the property under these circumstances, but a connection to
"notify::property_name" will not notice notifies emitted for
"property-name".
We can solve this by using the user's string to perform the lookup and
then using pspec->name for everything after that.
https://bugzilla.gnome.org/show_bug.cgi?id=684882
Prevent attempts to access keys ending with slashes that exist in the
schema file as references to child schemas.
Also: don't emit change signals for these same keys.
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.
g_settings_create_action() will create a GAction for the named key,
allowing it to be added to the action group of the application (so that
the setting can be directly manipulated from menus, for example).
https://bugzilla.gnome.org/show_bug.cgi?id=668279
This is strictly redundant now that we can get the ID from the schema
itself. Its only other purpose was to get the schema name from the
set_property() call to the constructed() call and we can avoid that by
doing the schema lookup at the time of the property being set.
These functions no longer have anything to do with GSettings itself, so
they should not be in that file anymore.
GSettings still wants direct access to the GSettingsSchemaKey structure,
so put that one in gsettingsschema-internal.h.
Add g_main_context_ref_thread_default(), which always returns a
reffed GMainContext, rather than sometimes returning a (non-reffed)
GMainContext, and sometimes returning NULL. This simplifies the
bookkeeping in any code that needs to keep a reference to the
thread-default context for a while.
https://bugzilla.gnome.org/show_bug.cgi?id=660994
This reverts commit c841c2ce3f.
This approach has been an unmitigated disaster. We're getting all sorts
of crashes due to functions that are returning NULL because they can't
find the schema for the default value. The people who get these crashes
are then confused about the root cause of the problem and waste a lot of
time trying to figure it out.
Until we find a better solution, we should go back to what we had
before.
https://bugzilla.gnome.org/show_bug.cgi?id=655366
This function implements the following logic:
if (g_variant_is_floating (value))
g_variant_ref_sink (value);
which is used for consuming the return value of callbacks that may or
may not return floating references.
This patch also replaces a few instances of the above code with the new
function (GSettings, GDBus) and lifts a long-standing restriction on the
use of floating values as the return value for signal handlers by
improving g_value_take_variant().
https://bugzilla.gnome.org/show_bug.cgi?id=627974
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
_GNU_SOURCE must be defined before including any other (system)
header, so defining it in glib-unix.h (and hoping no one has included
anything else before that) is wrong. And the "#define _USE_GNU"
workaround for this problem in gnetworkingprivate.h is even wronger
(and still prone to failure anyway due to single-include guards).
Fix this by defining _GNU_SOURCE in config.h when building against
glibc. In theory this is bad because new releases of glibc may include
symbols that conflict with glib symbols, which could then cause
compile failures. However, most people only see new releases of glibc
when they upgrade their distro, at which point they also generally get
new releases of gcc, which have new warnings/errors to clean up
anyway.
https://bugzilla.gnome.org/show_bug.cgi?id=649201
Without getting into a debate about the reasons why you may or may not
want to use unsigned integers, it's sufficient to note that people have
been using them and requesting this functionality.
Bug #641755.
The existing docs are a bit inconsistent in that they say to follow
the dbus convention, but then give an example that doesn't.
This commit changes things to be how Ryan says they should be.
