GNOME Bugzilla – Bug 693203
GtkApplication does not support Xfce session manager
Last modified: 2016-07-03 21:23:15 UTC
GtkApplication provides support to register the application with the session manager, e.g. GtkApplication* application = gtk_application_new("org.xfce.test", G_APPLICATION_FLAGS_NONE); g_object_set(G_OBJECT(application), "register-session", TRUE, NULL); However, when I run my application on Xfce I get: Gtk-WARNING **: Failed to register client: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name org.gnome.SessionManager was not provided by any .service files. Upon checking the code for gtkapplication, I've found that org.gnome.SessionManager is hardcoded in the source. Is it possible to provide support for Xfce session manager? (I'd like to shutdown my application gracefully on logout). Kind regards, Andrei.
Depends on what api the xfce session manager provides. GtkApplication does not currently offer much in terms graceful shutdown - you can use the GApplication::shutdown signal to do some last-minute cleanup.
(In reply to comment #0) > Gtk-WARNING **: Failed to register client: > GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name > org.gnome.SessionManager was not provided by any .service files. The same is shown under KDE, and on close two runtime critical warnings about application->priv->sm_client != NULL.
*** Bug 671084 has been marked as a duplicate of this bug. ***
Looking at the DBus API in xfce4-session, I can't see a method that allows a client to register/unregister itself in the XFCE session manager — clients can only use ICE or SM to register themselves. This is… sub-optimal, especially because it relies on X11. I looked all morning for the KDE session manager's code, but I could not find a Git repository, nor an API description that wasn't stuck to 2010, so I assume they are still using libSM or libICE as well, and ignoring the issue on Wayland. We could avoid warning if org.gnome.SessionManager does not have a service installed or could not be activated, and just use the fallback code paths like we do today. I'd rather support other session managers until the lower layers of the stack settle enough for somebody to propose an fd.o spec, but right now I don't see either of these things happening.
Finally found the KDE session manager, for both KDE 4 and KDE 5, and they are both XSMP session managers, which means they are pointless on Wayland. Since I very much doubt we're going to implement an XSMP-compliant session management policy inside GTK+ at this point (been there, done that, it cannot possibly work), we're going to need a decent replacement for the Wayland world, which likely means adapting the org.gnome.SessionManager DBus interface. We could also just punt this whole thing, and rely on the systemd user session to finally land; that way, systemd would track the lifetime of the application for us, which I guess would be the better long term option.
Created attachment 330478 [details] [review] Add support for the Xfce session manager Xfce4-session-manager added support for managing dbus based clients. This patch adds support for checking if Xfce session manager is around after trying the gnome one. With this patch gnome apps such as Devhelp now register with xfsm and happily do the QueryEndSession/EndSession/EndSessionResponse/Stop stuff.
It is of course a bit silly/sad to rename all the apis if the implemented interface is the same...
I didn't want to export it in Xfce as the Gnome session because we don't provide the full Gnome session dbus API. Most services just check if the proxy is there and then assumes all that functionality is present. Would you accept a patch that moved to a common org.gtk.SessionManager similar to org.gtk.Notification?
Well, we have to talk to the names that are actually on the bus, we can't just make up our own. So we'll probably have to go with something like your patch.
Review of attachment 330478 [details] [review]: ::: gtk/gtkapplication-dbus.c @@ +251,3 @@ + dbus->client_path, + GNOME_DBUS_CLIENT_INTERFACE, + &error); For figuring out the right client proxy to get, we should just look at g_dbus_proxy_get_name (dbus->sm_proxy), I think. No need to do the 'if service present' dance a second time.