_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.
GSettings relies on parts of the schema infromation remaining
unbyteswapped (the strinfo database, for example) while requiring other
parts to be in native order (the default value, constraints, etc.).
Lift the byteswapping into a place where we can do it selectively.
Move all the annotations over from gobject-introspection.
They will not be used directly by the introspection scanner for now,
instead they will be extracted by a script and updated manually
until introspection is properly integrated into the glib build
GSettings internally assumed that a change in key writability implied a
change in value. That may be true for some backends. Let those
backends deal with the situation for themselves.
When binding a boolean setting to a boolean property, invert the values.
This avoids the requirement for writing a pair of mapping functions for
this extremely common case.
Add a test.
https://bugzilla.gnome.org/show_bug.cgi?id=625833
Add a <flags> tag to the schema file format and a flags='' attribute to
go along with. Add some extra test cases for those.
Add new g_settings_{get,set}_flags() calls and support binding to
GParamSpecFlags properties. Add test cases.
Hold the GSettingsKeyInfo as part of the binding structure to save work
on each get/set. Use our copy of this structure to call the internal
get/set APIs. Give more descriptive error messages in the case of
invalid data on sets and retry using the translated default then schema
default value in case of failure to map on reads.
