Presently, Gtk will only send a startup notification completion message
for the first window that is shown. This is not good for the case of
GtkApplication, where we are expected to participate in
startup-notification for all windows.
We have avoided this problem by manually emitting the startup complete
message from after_emit in GtkApplication.
Unfortunately, this causes problems for windows that are shown with a
delay. It is also a dirty hack.
The reason for the original behaviour is simple: there is a static
boolean in gtkwindow.c which controls it. We remove this.
Instead, clear the startup notification ID stored in GDK when sending
the completion message. GtkApplication will re-set this the next time
an event comes in which needs startup-notification handling. In the
non-GtkApplication case, newly shown windows will still not send the
message, since the cookie will have been cleared.
Finally, we remove the hack from GtkApplication's after_emit.
This will probably cause some regressions in terms of lingering startup
notification messages. The correct solution here is to always use
gtk_window_present(), including when merely opening a new document (with
a new tab, for example).
https://bugzilla.gnome.org/show_bug.cgi?id=690791
When the $(resource_prefix)/gtk/help-overlay.ui resource exists,
load a GtkShortcutsWindow from it for each GtkApplicationWindow,
and set up a win.show-help-overlay action with accels <Primary>F1
and <Primary>? to show it.
gtk_application_shutdown clears the impl member, so all
callbacks, signal handlers, etc that might still be triggered
between a shutdown call and the return from the mainloop
better be prepared to deal with impl being NULL.
It can apparently happen that we get focus in events
on windows after gtk_application_shutdown() has been
called. Avoid an unnecessary crash in this case.
See
https://bugzilla.redhat.com/show_bug.cgi?id=1176339
This counterpart to gtk_application_get_accels_for_action() lets you
find out if a particular accelerator has one or more actions associated
with it. This might be useful from an accelerator editor or plugin
system to prevent the the installation of conflicting accelerators.
https://bugzilla.gnome.org/show_bug.cgi?id=721367
Use the new ::resource-base-path property on #GApplication to attempt to
load the menu layout of the application.
We look first at gtk/menus-appmenu.ui or gtk/menus-traditional.ui
depending on the setting of gtk_application_prefers_app_menu(). Failing
that, we fall back to the common case of gtk/menus.ui (which should
always be given). This provides a convenient way for application
authors to provide a different set of menus, depending on the desktop
environment they find themselves in.
As is the intention with other resources, if the resource base path is
unset, nothing will be loaded. Additionally, if the expected files are not
found, it is not an error -- just nothing happens.
https://bugzilla.gnome.org/show_bug.cgi?id=722092
Applications can call this to determine if they should an app menu.
This will be %FALSE on desktop environments that do not have an
application menu like the one in gnome-shell. It is %FALSE on Windows
and Mac OS.
Applications are completely free to totally ignore this API -- it is
only provided as a hint to help applications that may be interested in
supporting non-GNOME platforms with a more native 'look and feel'.
https://bugzilla.gnome.org/show_bug.cgi?id=722092
Drop the ref on the action muxer in finalize, and also make sure
shutdown() tears down the muxer setup done in startup().
When GtkApplication adds itself to a muxer, it causes the muxer to take
a ref on the GtkApplication. This has to be undone in shutdown() to make
sure the GtkApplication doesn't end up holding a ref on itself.
https://bugzilla.gnome.org/show_bug.cgi?id=730383
Add a new private API to GtkApplication akin to
gtk_widget_insert_action_group().
We'll use this to insert a few extra actions at the app level with a
separate namespace for the special items in the Mac OS application menu.
https://bugzilla.gnome.org/show_bug.cgi?id=720552
This header, which is not universally available, is accidently made to be
included unconditionally during the refactoring of gtkapplication.c,
so restore the #ifdef check.
gtkapplication.c has turned into a bit of an #ifdef mess over time, and
many of the current checks are incorrect. As an example, if you build
Gtk for wayland, and exclude the X11 backend, much of the functionality
required by wayland (such as exporting menu models) will be disabled.
Solve that by introducing a backend mechanism to GtkApplication (named
GtkApplicationImpl) similar to the one in GApplication. Add backends
for Wayland, X11 and Quartz, with X11 and Wayland sharing a common
'DBus' superclass.
GtkApplicationImpl
|
/--------------+-------------------\
| |
GtkApplicationImplDBus GtkApplicationImplQuartz
|
/-----------+-----------------\
| |
GtkApplicationImplX11 GtkApplicationImplWayland
GtkApplicationImpl itself is essentially a bunch of vfuncs that serve as
hooks for various things that the platform-specific backends may be
interested in doing (startup, shutdown, managing windows, inhibit, etc.)
With this change, all platform specific code has been removed from
gtkapplication.c and gtkapplicationwindow.c (both of which are now free
of #ifdefs, except for a UNIX-specific use of GDesktopAppInfo in
gtkapplicationwindow.c).
Additionally, because of the movement of the property-setting code out
of GtkApplicationWindow, the _GTK_APPLICATION_ID properties (and
friends) will be set on non-GtkApplicationWindows, such as dialogs.
https://bugzilla.gnome.org/show_bug.cgi?id=720550
Rework how accels are handled on GtkApplicationWindow.
Instead of having GtkApplication fill the GtkAccelMap which is then used
by GtkApplicationWindow to create a GtkAccelGroup filled with closures
that is then associated with the window, do it directly.
GtkApplication now keeps a list of accels and their actions.
Accelerators on a GtkApplicationWindow ask GtkApplication to execute the
appropriate action.
This saves a fair bit of complexity and memory use (due to not having to
create all those closures and accelmap entries). The new approach also
supports multiple accels per action (although there is not yet a public
API for it).
This patch (and the ones before) Reviewed and ACK'd by Matthias Clasen.
Previously, GtkWindow would add the "app" action group to its own
toplevel muxer.
Change the setup so that GtkApplication creates the toplevel muxer and
adds itself to it as "app". Use this muxer as the parent muxer of any
GtkWindow associated with the application.
This saves a small amount of memory and will allow for accels to be
propagated from the application through to all of the windows.
