This commit represents an API break to GAction in the following ways:
- the 'set_state' entry in the GActionInterface vtable has been
renamed to 'change_state'. The number and order of vtable items has
not otherwise changed.
- g_action_set_state() has been renamed to g_action_change_state() to
match the updated vtable entry.
- the "state" property of the GAction interface has been changed to
read-only to reflect the fact that g_action_set_state() no longer
exists.
- GSimpleActionClass has been hidden. GSimpleAction can no longer be
subclassed.
>> Rationale
g_action_set_state() has never been a true setter in the sense that
calling it will update the value of the "state" property. It has always
been closer to "request 'state' to be changed to this value" with
semantics defined by the implementor of the interface. This is why the
equivalent method in GActionGroup had its name changed from 'set' to
'change'. This change makes the two interfaces more consistent and
removes any implication about the effect that calling set_state() should
have on the 'state' property.
>> Impact
This incompatible API break was undertaken only because I strongly
suspect that it will go entirely unnoticed. If the break actually
affects anybody, then we will accommodate them (possibly going as far as
to revert this commit entirely).
The virtual table change only impacts implementors of GAction. I
strongly suspect that this is nobody (except for GSimpleAction).
The hiding of GSimpleActionClass only impacts impacts subclasses of
GSimpleAction. I strongly suspect that none of these exist.
The changing of the property to be read-only only affects people who
were trying to change the state by using GObject properties. I strongly
suspect that this is nobody at all.
The removal of the g_action_set_state() call is the most dangerous, but
I still suspect that it will impact nobody outside of GLib. If anybody
is impacted by this change then, at their request, I will reintroduce
the API as a deprecated alias for g_action_change_state().
Rather than having the gtk-doc build machinery have a list of header
files to exclude, change the GLib build to dump a list of public
header files generated from the maintained Makefile.am files for
each of glib/, gobject/, gio/.
Also, for glib, always install glib-unix.h, even on non-Unix
platforms, for the same reason we install gwin32.h even on Unix.
https://bugzilla.gnome.org/show_bug.cgi?id=651745
See https://bugs.freedesktop.org/show_bug.cgi?id=37890#c6 where it was
discovered that dbus-send(1) actually doesn't work (either libdbus-1's
flush implementation or dbus-send(1)'s usage of it is broken) so it's
useful to have here.
Signed-off-by: David Zeuthen <davidz@redhat.com>
This avoids the generated types (e.g. ExampleAnimal, ExampleCat,
ExampleObject and ExampleObjectManagerClient) being referenced in the
core gio docs. This was requested by Matthias.
Signed-off-by: David Zeuthen <davidz@redhat.com>
- remove all inline assembly versions
- implement the atomic operations using either GCC intrinsics, the
Windows interlocked API or a mutex-based fallback
- drop gatomic-gcc.c since these are now defined in the header file.
Adjust Makefile.am accordingly.
- expand the set of operations: support 'get', 'set', 'compare and
exchange', 'add', 'or', and 'xor' for both integers and pointers
- deprecate g_atomic_int_exchange_and_add since g_atomic_int_add (as
with all the new arithmetic operations) now returns the prior value
- unify the use of macros: all functions are now wrapped in macros that
perform the proper casts and checks
- remove G_GNUC_MAY_ALIAS use; it was never required for the integer
operations (since casting between pointers that only vary in
signedness of the target is explicitly permitted) and we avoid the
need for the pointer operations by using simple 'void *' instead of
'gpointer *' (which caused the 'type-punned pointer' warning)
- provide function implementations of g_atomic_int_inc and
g_atomic_int_dec_and_test: these were strictly macros before
- improve the documentation to make it very clear exactly which types
of pointers these operations may be used with
- remove a few uses of the now-deprecated g_atomic_int_exchange_and_add
- drop initialisation of gatomic from gthread (by using a GStaticMutex
instead of a GMutex)
- update glib.symbols and documentation sections files
Closes#650823 and #650935
For example, if setting a property on a skeleton from another thread
than where it was constructed, the idle handler responsible for
emitting the PropertiesChanged() signal could run immediately and
clear skeleton->priv->changed_properties_idle_source causing
g_source_unref() to be called with a NULL pointer. This race was
easily be fixed by adding a lock to the skeleton object.
In addition to fixing this race, also move the code for setting up the
idle handler to a class handler for the GObject::notify signal. This
change allows use of g_object_freeze_notify() and g_object_thaw_notify()
to perform atomic property changes from another thread than the one
that the skeleton was created in.
Signed-off-by: David Zeuthen <davidz@redhat.com>
.. and add a C setter to do this. Also make the C getter return a
reference since the property may be set from another thread. Also
change the constructor to _not_ take a GDBusConnection since this is
something you almost always want to do _after_ creating it. The
API/ABI break is fine as there has never been a GLib release with this
type.
https://bugzilla.gnome.org/show_bug.cgi?id=648959
Signed-off-by: David Zeuthen <davidz@redhat.com>
This new API allows watching a few select Unix signals;
looking through the list on my system, I didn't see anything
else that I think it'd reasonable to watch.
We build on the previous patch to make the child watch helper thread
that existed on Unix handle these signals in the threaded case.
In the non-threaded case, they're just global variables.
https://bugzilla.gnome.org/show_bug.cgi?id=644941
GLib historically has been designed to be "mostly" portable; there
are some functions only available on Unix like g_io_channel_unix_new(),
but these are typically paired with obvious counterparts for Win32.
However, as GLib is used not only by portable software, but components
targeting Unix (or even just Linux), there are a few cases where it
would be very convenient if GLib shipped built-in functionality.
This initial patch is a basic wrapper around pipe2(), including
fallbacks for older kernels. This pairs well with the
existing g_spawn_*() API and its child_setup functionality.
However, in the future, I want to add a signal() wrapper here,
complete with proxying the signal to a mainloop. I have initial code
for this, but doing it sanely (including factoring out gmain.c's
private worker thread), is a complex task, and I don't want to block
on that.
See also gwin32.h for Win32 specific functionality.
https://bugzilla.gnome.org/show_bug.cgi?id=644941
And use this for a) documentation purposes; and b) to preserve C ABI
when an interface is extended. See
https://bugzilla.gnome.org/show_bug.cgi?id=647577#c5
for more details. Also add test cases for this.
Signed-off-by: David Zeuthen <davidz@redhat.com>
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.
Make the schema argument to gsettings list-recursively optional.
This allows to search for not exactly known keys by going
gsettings list-recursively | grep 'font'
g_variant_new("as", NULL); now gives an empty array of strings, for
example.
This was documented as working already, but was never actually
implemented (due to the fact that it muddies the water when considering
maybe types). It's being implemented now because its convenience to
programmers exceeds any damage done to the conceptual purity of the API.
One new GUnicodeBreak enum member. Three new GUnicodeScript members,
and one member renamed to fix a typo.
Tests, docs, and scripts are updated. PCRE update still needed.
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.
This commit also changes (maintaining compatibility) the way
user-specified default applications are stored (as in, those for which
g_app_info_set_as_default_for_type() has been called.
We now store the default application for a content type in a new group
in the mimeapps.list keyfile, and "Added Associations" tracks only the
applications that have been added by the user, following a
most-recently-used first order.
This is useful in GtkAppChooser-like widgets to pre-select the last used
application when constructing a widget.
https://bugzilla.gnome.org/show_bug.cgi?id=636311
