Previously, dumping a GValue holding a GStrv just yielded "((GStrv *)
0xDEADBEEF)". I think it'd be more useful to dump a Python list-style
representation of the GStrv's contents, if it's not NULL.
Fixes: <https://bugzilla.gnome.org/show_bug.cgi?id=629192>
These functions are meant to replace the read_until() flavour, with the
following improvements:
- consistency between the synchronous and asynchronous versions as to
if the separator character is read (it never is).
- support for using a nul byte as a separator character by way of
addition of a length parameter which allows stop_chars to be treated
as a byte array rather than a nul-terminated string.
The read_until() functions are not yet formally deprecated, but a note
has been added to the documentation warning not to use them as they will
be in the future.
This is bug #584284.
The current msgctxt string 'GDateTime" lead to the unability to
differentiate between the full and abbreviated name for May.
Therefore, the msgctxt strings have been changed to
'full month name'
'abbreviated month name'
'full weekday name'
'abbreviated weekday name'
This is a string change, but all translations have been updated
using an sed script.
Bug 629429
This is a vtable structure and very likely the user has allocated it in
static storage and wants it to be const. Since we never modify it, no
harm is done to us to have it const.
Closes bug #629328.
Since we added g_object_notify_by_pspec(), an efficient way to install
and notify properties relies on storing the GParamSpec pointers inside
a static arrays, like we do for signal identifiers.
Instead of multiple calls to g_object_class_install_property(), we
should have a single function to take the static array of GParamSpecs
and iterate it.
https://bugzilla.gnome.org/show_bug.cgi?id=626919
Signed-off-by: Emmanuele Bassi <ebassi@linux.intel.com>
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.
The root problem is with GObject - for now, just work around it in
GDBus. Also include a test-case. See
https://bugzilla.gnome.org/show_bug.cgi?id=627724
for more information.
Signed-off-by: David Zeuthen <davidz@redhat.com>
- can not extend schemas that already have paths
- can not form list of schemas that already have paths
- the path of a list schema, if given, must end with ':/'
Ryan pointed out that it's safe to do this because we have the
G_DBUS_SEND_MESSAGE_FLAGS_PRESERVE_SERIAL flag and that it simplifies
how filter functions work.
Signed-off-by: David Zeuthen <davidz@redhat.com>
Since the previous commit, the g_unix_connection_send_credentials() /
g_unix_connection_receive_credentials() functions now also works on
FreeBSD since GUnixCredentialsMessage now works there.
The main idea is that the g_unix_connection_send_credentials() /
g_unix_connection_receive_credentials() functions are the "main" API
for getting credentials (one way or the other). So it's better to
avoid advertising where it is currently implemented.
Signed-off-by: David Zeuthen <davidz@redhat.com>
Otherwise things probably won't work in a garbage-collected world
(consider the trivial GC that never collects garbage).
This commit breaks GDBusServer ABI. No known released software is
using this code.
Signed-off-by: David Zeuthen <davidz@redhat.com>
Rework filter functions as per
https://bugzilla.gnome.org/show_bug.cgi?id=624546#c8
This commit breaks ABI. However, this ABI break affects only
applications using filter functions. The only known user of is dconf.
Signed-off-by: David Zeuthen <davidz@redhat.com>
Don't actually use this yet as that will require a couple of
modifications to the filter function signature. This is part of the
bug-fix for
https://bugzilla.gnome.org/show_bug.cgi?id=624546#c8
Signed-off-by: David Zeuthen <davidz@redhat.com>
This should fix bug #628952.
Don't include glib/gdatasetprivate.h directly. Especially don't define
GLIB_COMPILATION when doing that, as that causes breakage on Windows
because of the variable dllimport/dllexport stuff in gtypes.h that
checks GLIB_COMPILATION. That macro really should be defined only when
compiling code that goes into the libglib DLL. Otherwise the compiler
thinks that variables that should be imported from libglib are
actually defined in the code being compiled.
Just call g_atomic_pointer_get() as such, don't bother with
G_DATALIST_GET_FLAGS.
Signed-off-by: Tor Lillqvist <tml@iki.fi>
