As it turns out, we have examples of internal functions called
type_name_get_private() in the wild (especially among older libraries),
so we need to use a name for the per-instance private data getter
function that hopefully won't conflict with anything.
Since services are based on D-Bus activation and desktop files are
supposed to be named like the busname for DBusActivatable applications
and since gnome-shell wants wmclass equal to the desktop file name, we
therefore want wmclass equal to the application ID in this case.
wmclass is determined from the prgname, which is otherwise pretty
pointless to set to some random thing in $(libexec) for a D-Bus service,
so set that to the appid.
This means that for D-Bus services, the following things are now all the
same:
- application ID
- prgname
- wmclass property set on all windows
- desktop file name
- well-known bus name
There are not many applications running as D-Bus services at present so
this shouldn't impact anybody except for gnome-clocks (where this change
will be fixing a bug) and gnome-terminal.
https://bugzilla.gnome.org/show_bug.cgi?id=699259
This feature is intended for clients that want to signal a desktop shell
their busy state, for instance because a long-running operation is
pending.
The API works in a similar way to g_application_hold and
g_application_release: applications can call g_application_mark_busy()
to increase a counter that will keep the application marked as busy
until the counter reaches zero again.
The busy state is exported read-only on the org.gtk.Application interface
for clients to use.
https://bugzilla.gnome.org/show_bug.cgi?id=672018
The documentation was suggesting that using G_APPLICATION_IS_SERVICE
would automatically set an inactivity timeout (ie: app stays around for
a while after the use count drops to zero).
In reality, it only adds an initial 10 second wait for the first
activation message to arrive after which it uses the normal inactivity
timeout mechanism.
If we fail to start (and don't register() or call startup()) then also
don't call shutdown(). This happens in the case of failing to parse
commandline arguments, for example.
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
When the application is using its D-Bus backend, it is useful to be able
to export extra D-Bus objects at the right time, i.e. *before* the application
tries to own the bus name. This is accomplished here by adding a hook
in GApplicationClass for this; and a corresponding hook that will be called
on unregistration to undo whatever the register hook did.
Bug #675509.
Provide public access to the GDBusConnect and object path that
GApplication is using. Prevents others from having to guess these
things for themselves based on the application ID.
https://bugzilla.gnome.org/show_bug.cgi?id=671249
For a number of reasons it might be useful to register the object paths
associated with a non-unique application so that the application can at
least field requests to its unique D-Bus name.
https://bugzilla.gnome.org/show_bug.cgi?id=647986
This interfaceifies the extra functions that were on GDBusActionGroup
for dealing with platform data.
The two main benefits of doing this:
- no longer have to do a silly song and dance in GApplication to avoid
calling GDBusActionGroup API from non-dbus-aware code
- the interface can be reused by the action group exporter to avoid
ugly and unbindable hook callbacks
https://bugzilla.gnome.org/show_bug.cgi?id=665737
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
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.
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.
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.
