Almost identically to the previous commit, fix a similar latent bug in
`g_dbus_connection_export_action_group()`, which was not ready to handle
the fledgling `GActionGroupExporter` being freed early on an error
handling path.
See the previous commit message for details of the approach.
This includes a unit test.
Signed-off-by: Philip Withnall <pwithnall@gnome.org>
Fixes: #3366
Since we have a convenience method to add actions let's allow to remove
them just as easily. This makes resource cleanup as simple as initially
adding the entries.
The action name, parameter and new state are all controlled by an
external process, so can’t be trusted. Ensure they are validated before
being passed to functions which assert that they are correctly typed and
extant.
Add unit tests.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #1904
Instead, iterate the `GMainContext` directly. This allows tests on
asynchronously returned values to be done in the actual test function,
rather than a callback, which should make the tests a little clearer.
This introduces no functional changes.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
These headers have all been written manually, by looking through the git
log for each file and noting the copyright of each significant
contribution.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
Helps: #1415
The public `g_strv_contains()` API didn’t exist at the time this code
was originally written. Now, happily, it does.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
These are known leaks, as they were being done in tests which were
checking precondition failures.
However, since we know what happens when the failures occur, we can
still free the input data reliably, so do that.
This improves the valgrind output for `actions` to show zero definite
leaks.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
The `actions` test previously waited an arbitrary 100ms for various
D-Bus messages to be sent/received, before checking the results of those
messages.
Normally, this would work, but on heavily loaded CI systems, it would
sometimes fail. For example,
https://gitlab.gnome.org/GNOME/glib/-/jobs/1611701.
Fix that by waiting for the condition being checked to evaluate to true,
rather than waiting an arbitrary period of time. On faster machines,
this will speed the tests up too.
Assume that the global default `GMainContext` is in use, so a
`GMainContext*` pointer doesn’t have to be passed around.
Signed-off-by: Philip Withnall <pwithnall@endlessos.org>
gio/tests/actions.c: In function ‘strv_set_equal’:
gio/tests/actions.c:177:41: error: comparison of integer expressions of different signedness: ‘guint’ {aka ‘unsigned int’} and ‘gint’ {aka ‘int’}
177 | res = g_strv_length ((gchar**)strv) == count;
| ^~
gio/tests/actions.c: In function ‘test_parse_detailed’:
gio/tests/actions.c:473:17: error: comparison of integer expressions of different signedness: ‘gint’ {aka ‘int’} and ‘long unsigned int’
473 | for (i = 0; i < G_N_ELEMENTS (testcases); i++)
| ^
gio/tests/actions.c: In function ‘test_entries’:
gio/tests/actions.c:375:5: error: missing initializer for field ‘parameter_type’ of ‘GActionEntry’ {aka ‘const struct _GActionEntry’}
375 | { "foo", activate_foo },
| ^
In file included from gio/gio.h:31,
from gio/tests/actions.c:1:
gio/gactionmap.h:63:16: note: ‘parameter_type’ declared here
63 | const gchar *parameter_type;
| ^~~~~~~~~~~~~~
...
Reduce the number of iterations of things sent over a mock session bus
from different threads, to avoid the test spending quite so long
contested over the `gsignal.c` lock.
The test now takes about 10 seconds, according to `time`, rather than
around 100 or longer.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
g_assert_*() give more informative failure messages, and aren’t compiled
out when building with G_DISABLE_ASSERT.
Signed-off-by: Philip Withnall <withnall@endlessm.com>
This can be handy when you want to change the sense of a toggle
in the UI without rewriting the underlying logic. Currently, this
is just exposed as a construct-only property. We may add a
convenience wrapper or a special !property syntax for this later.
https://bugzilla.gnome.org/show_bug.cgi?id=728489
The actions test tests the GSimpleActionGroup API. Maybe this
should be moved to use GActionMap, but for now, just disable
the deprecations.
There was also one test that wasn't actually hooked up, so
do that as well.
Add a new type of GAction that represents the value of a property on an
object. As an example, this might be used on the "visible-child-name"
property of a GtkStack.
https://bugzilla.gnome.org/show_bug.cgi?id=703270
Expand and formalise the syntax for detailed action names, adding a
well-documented (and tested) public parser API for them.
Port the only GLib-based user of detailed action names to the new API:
g_menu_item_set_detailed_action(). The users in Gtk+ will also be
ported soon.
https://bugzilla.gnome.org/show_bug.cgi?id=688954
Very many testcases, some GLib tools (resource compiler, etc) and
GApplication were calling g_type_init().
Remove those uses, as they are no longer required.
https://bugzilla.gnome.org/show_bug.cgi?id=686161
Some of the GLib tests deliberately provoke warnings (or even fatal
errors) in a forked child. Normally, this is fine, but under valgrind
it's somewhat undesirable. We do want to follow fork(), so we can check
for leaks in child processes that exit gracefully; but we don't want to
be told about "leaks" in processes that are crashing, because there'd
be no point in cleaning those up anyway.
https://bugzilla.gnome.org/show_bug.cgi?id=666116
Have one simple _get() API that returns the group immediately, in an
empty state. The group is initialised on the first attempt to interact
with it.
Leave a secret 'back door' for GApplication to do a blocking
initialisation.
Exporting can only be done relative to a particular given main context
and all interaction with the action group must be on that same context.
Fix up the implementation so that the user can specify that context with
the normal (thread default) mechanism and document the limitation on the
API.
Adjust the testcase to adhere to the documentation limitations. It
passes now.
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().
Makes explicit the fact that you are interacting with the individual
action rather than the group and removes potential namespace conflicts
with classes implementing the interface (like g_application_activate()
vs g_application_activate_action()).
