Unlike g_application_register, there is no public API to unregister the
GApplication from D-Bus. Therefore, if the GApplication is set up
manually without using g_application_run, then neither can the
GApplicationImpl be destroyed nor can dbus_unregister be called before
destruction.
This is fine as long as no sub-class has implemented dbus_unregister.
If they have, their method method will be called after destruction, and
they should be prepared to deal with the consequences.
As long as there is no public API for unregistering, let's demote the
assertion to a WARNING. Bravehearts who don't use g_application_run
can continue to implement dbus_unregister, but they would have been
adequately notified.
This reverts commit c1ae1170fa.
https://bugzilla.gnome.org/show_bug.cgi?id=725950
Invoking the dbus_unregister virtual method during destruction is
problematic. It would happen after a sub-class has dropped its
references to its instance objects, and it is surprising to be asked to
unexport exported D-Bus objects after that.
This problem was masked as a side-effect of commit 21b1c390a3.
Let's ensure that it doesn't regress by asserting that dbus_unregister
has happened before destruction.
Based on a patch by Giovanni Campagna.
https://bugzilla.gnome.org/show_bug.cgi?id=725950
If we have an input parameter (or return value) we need to use (nullable).
However, if it is an (inout) or (out) parameter, (optional) is sufficient.
It looks like (nullable) could be used for everything according to the
Annotation documentation, but (optional) is more specific.
Some applications support running in a mode where they present
themselves as a different application to the user (for example web
browsers or terminals).
To facilitate this, add an option --gapplication-app-id which allows
users to override an application's id from desktop files or similar.
Applications need to opt-in to this by setting the
G_APPLICATION_CAN_OVERRIDE_APP_ID flag.
https://bugzilla.gnome.org/show_bug.cgi?id=743933
As g_win32_get_command_line() calls CommandLineToArgvW() to acquire the
arguments passed into a GApplication program, it actually returns the
whole command line which is used to invoke the program, including the
script interpreter and its flags when a script using GNOME bindings
(e.g. PyGObject and so on) is being invoked.
The issue here is that g_application_run() would most probably have
trouble in the scripts scenario on Windows as it is likely unable to
"recognize" the script interpreter, causing such scripts to fail to run.
Largely based on the patch by Ray Donnelly <mingw.android@gmail.com>.
https://bugzilla.gnome.org/show_bug.cgi?id=734095
Otherwise, we'll acquire it on every loop iteration, which can leave us
vulnerable to racing another thread for the acquisition of the main
context.
This can break methods like g_main_context_invoke, which try to acquire
a context to figure out if it can invoke the method synchronously or
need to defer to an idle. In these cases, it isn't guaranteed that the
invocation function will be invoked in the default main context,
e.g. the one that GApplication is holding.
This also matches what GMainLoop is doing.
https://bugzilla.gnome.org/show_bug.cgi?id=752983
It's theoretically possible (and see in the wild) for D-Bus messages to
come in to the application after shutdown() has been called and while
we're draining out the lingering events in the main context.
Prevent this from happening by ensuring we unregister our objects on
D-Bus during the shutdown process.
https://bugzilla.gnome.org/show_bug.cgi?id=757372
A signal accumulator can return TRUE to continue signal emission, and
FALSE to stop signal emission. handle-local-options callbacks can return
« return a non-negative option if you have handled your options and
want to exit the process ».
Currently, g_application_handle_local_options_accumulator (the
accumulator for the handle-local-options signal) returns TRUE on
non-negative return value (ie continue signal emission), and returns
FALSE on negative return values (ie when the default option processing
should continue).
This return value seems backward as on >= 0 values, subsequent
handle-local-options callbacks could overwrite the 'exit request' from
the handler, while on < 0 values, the handle-local-options processing
could end up early if several callbacks are listening for this signal.
In particular, the default handler for this signal
(g_application_real_handle_local_options) always returns -1 and will
overwrite >= 0 return values from other handlers.
This commit inverts the check so that signal emission stops early when
one of the handle-local-options callbacks indicates it wants processing
to stop and the process to exit.
https://bugzilla.gnome.org/show_bug.cgi?id=751598
Make sure to initialize the notification backend in
g_application_withdraw_notification() the same way as is done in
g_application_send_notification().
This makes it possible for an app to withdraw notifications it has sent
in a previous execution of the application.
https://bugzilla.gnome.org/show_bug.cgi?id=750625
Currently, applications using g_application_add_main_option_entries()
won't get translated entries in --help output. We need to call
g_option_group_set_translation_domain() with a NULL domain to ensure that the
default application gettext domain (ie the one passed to the
textdomain() call) will be used for the main entries passed by the
application.
If we want to allow more flexibility on which gettext domain should be
used for these entries, new API will be needed.
https://bugzilla.gnome.org/show_bug.cgi?id=750322
If someone explicitly calls g_application_quit() then don't attempt to
drain the mainloop of remaining sources.
This allows applications with 100% CPU utilisation to quit reliably.
https://bugzilla.gnome.org/show_bug.cgi?id=744876
After ::shutdown, run the mainloop until all pending activity is
handled, before returning from run().
Among other things, this gives a chance for destroyed windows to be
properly withdrawn from the windowing system.
https://bugzilla.gnome.org/show_bug.cgi?id=744876
g_application_bind_busy_property() had the restriction that only one
property can be bound per object, so that NULL could be used to unbind.
Even though this is enough for most uses, it is a weird API.
Lift that restriction and add an explicit unbind function.
https://bugzilla.gnome.org/show_bug.cgi?id=744565
GApplication set the prgname to the application's id when it was running
in service mode. This broke with the addition of new --app-id option,
because g_set_prgname() was called before parsing the options. Calling
it after option parsing doesn't work, because GOptionContext sets
prgname to argv[0] unconditionally.
Instead of changing the semantics of GOptionContext, simply remove this
functionality from GApplication. It is very unusual to have the prgname
set to the app id instead of the binary's name and might confuse people
when looking at logs etc.
When overriding local_command_line() from a subclass,
g_option_context_parse() might never be invokded. Thus, continue setting
the prgname to argv[0] in GApplication.
https://bugzilla.gnome.org/show_bug.cgi?id=743933
Balancing g_application_{un,}mark_busy() is non-trivial in some cases.
Make it a bit more convenient by allowing to bind multiple boolean
properties (from different objects) to the busy state. As long as these
properties are true, the application is marked as busy.
https://bugzilla.gnome.org/show_bug.cgi?id=744565
This should already work according to the documentation, but doesn't
because main_options is consumed before the check in
g_application_parse_command_line().
Fix by moving the check for main_options up.
https://bugzilla.gnome.org/show_bug.cgi?id=740157
This function adds a single main option entry to be handeled by
GApplication. The option entry has it arg_data field set to NULL
and will be added to the applications packed_options.
The rationale for this is that bindings will be able to add
command line options even when they can't use the un-boxed struct
GOptionEntry.
https://bugzilla.gnome.org/show_bug.cgi?id=727455
We don't use this for anything inside of GApplication yet, but Gtk is
about to start using it to find various bits of the application (such as
its menus, icons, etc.).
By default, we form the base path from the application ID to end up with
the familiar /org/example/app style.
https://bugzilla.gnome.org/show_bug.cgi?id=722092
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
