Now that we're a GActionMap the story about propagating signals from our
(now-constant) internal action group is vastly simplified. If someone
calls g_application_set_action_group() then signals will stop working --
but this function is deprecated and they never worked before, so no big
loss there.
https://bugzilla.gnome.org/show_bug.cgi?id=643736
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
Various places in the code were assuming that the hash table was always
available. Fix this, and also avoid leaking strings now that the hash
table may be NULL.
Based on a patch by Simon McVittie, bug 666167
g_main_loop_quit() only quits mainloops that are currently running --
not ones that may run in the future. The way the gdbus-threading tests
are written can possibly result in a call to g_main_loop_quit() before
g_main_loop_run() has started.
The mainloops aren't actually used for anything other than signalling
the completion of the threads, so just use g_thread_join() for that.
https://bugzilla.gnome.org/show_bug.cgi?id=666129
When trying to compile glib master on a RHEL 6.2 system, it fails with:
make[4]: Entering directory `/home/teuf/gnome/src/glib/gio'
CC libgio_2_0_la-gnetworkmonitornetlink.lo
In file included from gnetworkmonitornetlink.c:25:
/usr/include/linux/netlink.h:35: error: expected specifier-qualifier-list before 'sa_family_t'
gnetworkmonitornetlink.c: In function 'g_network_monitor_netlink_initable_init':
gnetworkmonitornetlink.c:99: error: 'struct sockaddr_nl' has no member named 'nl_family'
gnetworkmonitornetlink.c💯 error: 'struct sockaddr_nl' has no member named 'nl_pid'
gnetworkmonitornetlink.c💯 error: 'struct sockaddr_nl' has no member named 'nl_pad'
gnetworkmonitornetlink.c:101: error: 'struct sockaddr_nl' has no member named 'nl_groups'
make[4]: *** [libgio_2_0_la-gnetworkmonitornetlink.lo] Error 1
sa_family_t is defined in sys/socket.h, this commit makes sure this header is included before netlink.h
This fixes bgo bug #666001
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.
This was causing the following critical when running bloatpad twice:
GLib-CRITICAL **: g_hash_table_insert_internal: assertion `hash_table != NULL' failed
Clean up the docs for GApplication and related classes.
I'm no longer writing documentation for the structure type of classes
and interfaces. See https://bugzilla.gnome.org/show_bug.cgi?id=665926
for discussin on the correct way forward on this point.
Also: stop putting gtk-doc comments in installed headers.
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.
GDBusConnection now dispatches GDestroyNotify calls back to the
mainloop. Adding an idle to the mainloop is O(n) in the number of idles
already there. We therefore need to periodically empty the mainloop to
avoid quadratic behaviour with a very large 'n'.
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.
Sometimes randa and randb end up having the same state, causing them to
return the same stream of 'random numbers'. This is a problem for the
testcase that is looping to find unequal menus.
If we find ourselves in this state, throw one of the random generators
away and recreate it so we have a better chance of getting some unequal
menus.
Give it the same treatment as the exporter for GActionGroup just got.
There is a wart here: the exporter attempt to re-enter GDBusConnection
when it is freed in order to cancel outstanding name watches.
GDBusConnection holds its own lock while calling the destroy notify, so
the attempt at reentrancy results in a deadlock.
We have a workaround to deal with that for now...
Allow the menu to be changed after registration. This is quite useful
for setting up the menus from the ::startup handler instead of having to
do it before registration because it lets you skip the work if you're
not the primary instance.
The error handling on register() was just totally out of hand before.
Clean that mess up.
Take out the menu export for now as well. It will be added back again
later.
Rename g_application_set_menu to g_application_set_app_menu and make a
couple of fixups. Clarify the documentation about exactly what this
menu is meant to be.
Add g_application_set_menubar and document that as well.
This is an interface to represent GSimpleActionGroup-like objects (ie:
those GActionGroups that operate by containing a number of named GAction
instances).
Create a 'mirror' model of the proxy for the testcase. In addition to
testing that the proxy model emits the proper signals this also keeps
the proxy alive (by holding references to it from the mirror).
The previous code would create the submenu proxies and destroy them
right away (from the recursive step in the equality comparison
functions). This means that the subscription would go out over D-Bus
and the proxy would be destroyed before it returned. Keeping the model
alive allows it to be actually updated.
Only resolve the link at the point that we pull it through the API
rather than at the point that we first are told about it. This reduces
the lifespan of subscriptions and, more importantly, avoids a tricky
reference cycle issue.
Each test needs to remove the sources that it attaches
to the default main context, or else things will work
fine in isolation, but go bad in a full test run.
The code assumes in various places that ':' does not occur
in attribute names. We are a little more strict than that,
and only allow lowercase ASCII, digits and '-'.
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
