In order to maintain a logical stream of events, we need to make sure we
flush and queued change notifications before responding to any requests
for information from clients.
If we don't do this, it's possible that we emit an 'add' event that was
queued at the time of a 'DescribeAll' call _after_ the reply to that
call (which already contained the description of the new action).
In practice, this is not only logically incorrect, but it can also cause
problems. If a change to action 'state' or 'enabled' occurs after the
DescribeAll but before the signal has been dispatched, it will be
ignored because an 'add' signal is already pending. When that add
signal is sent, it will contain the correct data, but the receiver will
ignore it because it already saw the action in the DescribeAll reply.
https://bugzilla.gnome.org/show_bug.cgi?id=749693
If someone calls org.gtk.Actions.Describe on a non-existent action then
return an exception instead of a trivial description (disabled, no
state, etc.).
https://bugzilla.gnome.org/show_bug.cgi?id=687185
If someone calls org.gtk.Actions.Describe on a non-existent action then
return an exception instead of a trivial description (disabled, no
state, etc.).
https://bugzilla.gnome.org/show_bug.cgi?id=687185
Even private functions that are actually called across compilation
units should have prototypes. For g_dbus_action_group_sync(), create
one in gdbusactiongroup-private.h
https://bugzilla.gnome.org/show_bug.cgi?id=687385
We provide a mechanism by which a 'platform' (eg: Gtk) can register some
hook functions to be called to collect platform-data at the point of
sending an outgoing action activation request and also to inform the
platform of this data on incoming requests (before and after dispatching
the actual request).
This can be used for forwarding timestamp and startup-notification
information (as is presently done in GApplication) but the before/after
hook could also be used for acquiring/releasing the Gdk lock or other
similar things.
https://bugzilla.gnome.org/show_bug.cgi?id=665737
GDBusConnection recently changed to dispatching its GDestroyNotify calls
from an idle instead of on-the-spot. Under the previous regime, we
would destroy-notify the action group export of a GtkApplicationWindow
at the point it was removed from the application (ie: slightly before
being disposed).
With the destroy notify now deferred to an idle, the window has already
been disposed, so the signal handlers have already been disconnected.
Avoid the problem by dropping our use of signal IDs and just do
g_signal_handlers_disconnect_by_func(), which doesn't complain if there
is no connection.
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.
There are no public 'exporter' objects, so don't allude to them
in the function names. At the same time, we want to make it clear
that these functions are D-Bus specific.
The new APIs are
g_action_group_dbus_export_start
g_action_group_dbus_export_query
g_action_group_dbus_export_stop
g_menu_model_dbus_export_start
g_menu_model_dbus_export_query
g_menu_model_dbus_export_stop
