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
We don't expose ::quit-requested as API anymore. Instead, we expect
users to register inhibitors when needed. Without quit-requested,
there is no need for ::quit-cancelled and gtk_application_quit_response
anymore.
We still emit ::quit when the application is about to quit.
Replace all references to g_application_set_app_menu and
g_application_set_menubar by their gtk variants, which
actually exist. Pointed out in bug 667546
The function definition used a pointer to the enum value rather than the enum
itself.
This broke the build on platforms that don't have an implmentation of these
functions.
This lets applications block logout and similar actions ahead
of time. Currently only implemented for D-Bus, but Windows has
very similar API since Vista.
This is fairly basic, allowing applications to learn when
the session manager is about to end the session, and possibly
block this. The only implementation at this point is using the
org.gnome.SessionManager D-Bus interface of gnome-session. It should
be straightforward to port the EggSMClient implementations for
Windows and OS X.
We add the app-menu and menubar public APIs to GtkApplication while
leaving the implementation in GApplication.
The actual implementation will be moved soon.
When we have incoming activations or action invocations we should
acquire the GDK lock, just in case the program in question is using gdk
threads.
https://bugzilla.gnome.org/show_bug.cgi?id=665737
This allows to specify accelerators in a convenient way, by
adding accel="..." attributes to the menu items in the
XML for the menu.
Currently, the accelerators are extracted only once, when the
menu property is changed on the application.
Move internal accel map API there and update all users.
Also, add an internal function to create an accel path for
an action and parameter, and use it in gtkapplication.c and
gtkmodelmenuitem.c instead of duplicating that code.
This is a GtkWindow subclass that "application windows" will use. Each
is associated with a GtkApplication, has the ability to show menus and
will have its own associated set of actions.
This should be redone to show the label together with the
separator line, somehow. For now, just put the label below
the separator, as a separate item.
Removing the window from the window list before setting the
application to %NULL avoids gtk_application_remove_window() triggering
another call to gtk_application_window_removed(), which would release
the application a second time.
https://bugzilla.gnome.org/show_bug.cgi?id=653053
