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.
Applications have no way of finding out if a session manager proxy was
successfully created in gtk_application_startup_session_dbus(), so it's not
appropriate for certain public GtkApplication functions to be asserting the
presence of a session manager proxy as if it were a programmer error.
This affects:
gtk_application_inhibit()
gtk_application_is_inhibited()
If sm_proxy is NULL, the function should just return silently.
In the case of gtk_application_uninhibit(), the application should only be
calling this if it obtained a valid cookie, which implies the presence of a
session manager proxy. I noted that with a comment.
https://bugzilla.gnome.org/show_bug.cgi?id=701365
This is fallout from commit 257b42e2f9 -
those fields were already getting freed in
gtk_application_shutdown_x11() and my commit caused crashes on quit
instead.
Thanks to Rico Tzschichholz for reporting the bug and testing this fix.
Makes name consistent with other quartz-only modules and makes it clear that this works with the GMenuModel system rather than the older GtkMenu system.
GApplication now makes the session bus and object path available as a
public API on the application instance. Use that instead of trying to
guess values for ourselves.
This causes this version of Gtk+ to depend on GLib 2.32.2, so bumping
version dependency accordingly.
https://bugzilla.gnome.org/show_bug.cgi?id=671249
We currently have a couple of cases where GtkApplication assumes that
the session bus will be non-NULL causing critical error output or (in
the case of trying to publish menus) an infinite loop.
Three fixes:
- if the session bus is NULL due to not having registered the
GtkApplication yet then give a g_critical on the entry point to the
menu setters instead of going into an infinite loop. Document this.
- check for NULL session bus even when calling the menu setters at the
right time in order to prevent the infinite loop for
non-programer-error cases (ie: because we had trouble connecting to
the session bus)
- check for NULL session bus when publishing the X11 properties on the
GtkApplicationWindow and skip publishing them if we're not on the bus
https://bugzilla.gnome.org/show_bug.cgi?id=671249
gtk_application_set_app_menu(), gtk_application_set_menubar():
Mention that you probably want to call this in the startup signal
handler. If you do it earlier you will likely get a warning about
a missing D-Bus connection, because doing it earlier does not
make sense anyway.
Instead of firing a 'quit' signal and expecting the application to do
something that will cause it to quit, just call the new
g_application_quit() API for ourselves.
https://bugzilla.gnome.org/show_bug.cgi?id=670485
This seems a bit "too powerful" and unlikely to be used by most
applications. Remove it from now, until someone comes up with a strong
desire for it.
https://bugzilla.gnome.org/show_bug.cgi?id=670485
