Visual C++ is quite zealous about checking against the types used in the
initializing of array of structures, even up to Visual C++ 2013. Fix this
by splitting up the initializing steps.
https://bugzilla.gnome.org/show_bug.cgi?id=724609
Add support for parsing command line options with GApplication.
You can add GOptionGroup and GOptionEntry using two new APIs:
g_application_add_option_group() and
g_application_add_main_option_entries().
Also add a "handle-local-options" signal that allows handling of
commandline arguments in the local process without having to override
local_command_line.
As a special feature, you can have a %NULL @arg_data in a GOptionEntry
which will cause the argument to be stored in a GVariantDict. This
dictionary is available for inspection and modification by the
"handle-local-options" signal and can be forwarded to the primary
instance in cases of command line invocation (where it can be fetched
using g_application_command_line_get_options()).
https://bugzilla.gnome.org/show_bug.cgi?id=721977
Clarify in the documentation that the commandline arguments passed
around by GApplication (to local_command_line and returned via
g_application_command_line_get_arguments()) are in the GLib filename
encoding (ie: UTF-8) on Windows, not the system code page.
Fix the mismatch that would result from having argv passed to
g_application_run() in main() on Windows (where it is in the system
code page) by ignoring argc/argv on Windows and calling
g_win32_get_command_line() for ourselves. Document this.
This might be a slight API break on Windows: we documented that it was
possible to call g_application_run() with arguments other than argc/argv
and now doing that will result in those arguments being ignored. It has
always been recommended practice to only call g_application_run() from
main() directly, however, and all of our code examples have shown only
this. We will see if this causes any issues and consider reevaluating
the situation if so.
https://bugzilla.gnome.org/show_bug.cgi?id=722025
The default local_command_line handler has a fast return path for the
case that we handle the commandline by forwarding it to the primary
instance, but this doesn't account for the fact that we may want to
become a service.
Allow for this by making sure we don't take the fast path of the service
flag is set.
Add a --gapplication-service switch to the default implementation of
local_command_line. This name is unlikely to clash with any option used
by an existing application.
When a normal application (neither service nor launcher) is launched with
exactly this one argument, G_APPLICATION_IS_SERVICE will be set.
The idea is that people will write their D-Bus service file with
--gapplication-service on the Exec line. This provides a nice
compromise for people who want the benefits of DBusActivatable
applications but without losing the ability to easily run them directly
(under the debugger or inside jhbuild, etc.)
https://bugzilla.gnome.org/show_bug.cgi?id=710965
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.
To help cross compilation, don't use glib-genmarshal in our
build. This is easy now that we have g_cclosure_marshal_generic().
In gobject/, add gmarshal.[ch] to git (making the existing entry
points stubs).
In gio/, simply switch to using g_cclosure_marshal_generic().
https://bugzilla.gnome.org/show_bug.cgi?id=652168
Call g_settings_sync() just before g_applcation_run() returns. This is
really the correct thing to do in every case that you're using GSettings
and it prevents every single application from having to do it for
themselves.
Closes bug #647419.
Add a flag to essentially short-circuit g_application_register(). The
application makes no attempt to acquire the bus name or check for
existing instances with that name. The application is never considered
as being 'remote' and all requests are handled locally.
Closes#646985.
* gio/application.c (g_application_real_command_line): Check that the
default signal handler is not the current one before complaining, because
it is not unusual for overloads to call the base class implementation as
a matter of habit.
g_application_real_open() and g_application_real_activate() already do this
extra check.
Some people are trying to write code that calls g_application_register()
then checks to see if we became the primary name owner before exporting
objects. This sort of approach worked with libdbus-1 because method
calls to the freshly-acquired name would not be dispatched until the
application returned to the mainloop. With GDBus, however, dispatches
can occur at any time (including in the brief space between acquiring
the name and actually registering the object).
Add documentation to make it clear that you should not expect this to
work.
