GNOME Bugzilla – Bug 671802
no menu fallback with ssh -X or sudo
Last modified: 2014-12-24 14:09:27 UTC
Running Gtk applications over 'ssh -X' or inside of sudo means that the application doesn't connect to the same session bus as the rest of the session and the menus don't get displayed in the shell. That's fine -- there's really no way we can easily make this work. The problem is that the fallback case doesn't work either. The application sees the "shell shows appmenu" property set in the XSettings and hides its local copy of the menu. One idea for handling this is to have a session record the guid of the D-Bus session bus into the X server so that applications can tell that they are "outside of the session" (by comparing the ID of their local session bus to the "real" one). Attached is a gnome-session patch to do exactly that. The problem here is that D-Bus seems to have two concepts of unique IDs. One is assigned to the bus daemon itself -- which is the one we'd expect to use. The 'guid' seen in the $DBUS_SESSION_BUS_ADDRESS variable and returned from g_dbus_connection_get_guid() is not the same as this one, though -- it's a unique identifier that is assigned to each separate listening port on the dbus daemon (and unrelated to the daemon's internal ID). We should decide which one is appropriate to use or come up with something else entirely.
Created attachment 209416 [details] [review] gsm: export the D-Bus GUID as a root window prop For a long time we'd had a problem where applications started over 'ssh -X' or in sudo have a connection to the X server, but not the session bus. dbus-launch automaticallly gives these apps their own private session bus. The applications don't know that they're not on the same session bus as the rest of the session and can behave badly. gnome-session now publishes its idea of the session bus GUID as an X property that clients can check against their view to find out if they should expect various bits of session API to actually work.
Could just check for org.gnome.SessionManager being taken on the bus. If you are all alone on your bus, then menus won't work.
Using plain X11 instead of dbus as message bus wouldn't work out of box?
Tunneling the description of a menu layout as X client messages is not my idea of a good time...
*** Bug 687971 has been marked as a duplicate of this bug. ***
*** Bug 703862 has been marked as a duplicate of this bug. ***
*** Bug 721840 has been marked as a duplicate of this bug. ***
*** Bug 700384 has been marked as a duplicate of this bug. ***
Created attachment 293013 [details] [review] GtkApplication: Try to cope with ssh situations better We are looking for org.gnome.SessionManager on the bus anyway, so we can use this information to override the gtk-shell-shows-app-menu and gtk-shell-shows-menubar settings. If we can't find gnome-session on the bus, then it very likely that we are in an ssh situation where we see the forwarded X display, but not the session bus. The D-Bus based menu exporting will not work in this situation.
Here (finally) is the alternative approach outlined in comment 2. Sadly, this does not fully resolve the ssh situation, since we still see the gtk-decoration-layout xsetting, which g-s-d is setting to ":close", so we don't get a local app menu fallback. Maybe g-s-d should be changed to make it "menu:close" to cover this eventuality.
Review of attachment 293013 [details] [review]: I don't like how this overrides GtkSettings, but if it gets the job done, I would be OK with that sort of approach in general... The big problem here is that it effectively hardcodes a dependency on GNOME. Other desktops set shell-shows-app-menu and shell-shows-menubar as well, and certainly we don't want to prevent their users from enabling those settings (either by way of xsettings or, as a last resort their gtk config file). So I'm OK with the jamming-the-settings approach, but only in case of a much stronger "dbus is not working right" signal. I think that necessarily involves some mechanism for being able to identify that the xsettings provider (that we see via X11) is not on the same bus with us. If they're not, then we should feel free to nuke their settings. Open question: do we still want to respect the ini file in that case?
(In reply to comment #11) > Review of attachment 293013 [details] [review]: > > I don't like how this overrides GtkSettings, but if it gets the job done, I > would be OK with that sort of approach in general... > > The big problem here is that it effectively hardcodes a dependency on GNOME. > Other desktops set shell-shows-app-menu and shell-shows-menubar as well, and > certainly we don't want to prevent their users from enabling those settings > (either by way of xsettings or, as a last resort their gtk config file). Your suggestion was to set a property in gnome-session. I am looking for gnome-session on the bus. I don't see any difference in the level of gnome dependency... > So I'm OK with the jamming-the-settings approach, but only in case of a much > stronger "dbus is not working right" signal. I think that necessarily involves > some mechanism for being able to identify that the xsettings provider (that we > see via X11) is not on the same bus with us. If they're not, then we should > feel free to nuke their settings. If you want to export the guid as an xsetting, instead of a root window property, that would be a way to get out of the 'hardcodes gnome-session' issue. At the cost of hardcoding gsd...
Created attachment 293015 [details] [review] Add an XSetting for the session bus ID This will allow us to identify situations where we are not on the same session bus as the xsettings provider.
Created attachment 293016 [details] [review] GtkApplication: Try to cope with ssh situations better Override the gtk-shell-shows-app-menu and gtk-shell-shows-menubar settings to FALSE, if we can detect that we are not on the same session bus as the xsettings provider that we got these settings from. We determine this by comparing the bus ID of 'our' session bus with the one reported in the Gtk/SessionBusId xsetting. If they are different, then it very likely that we are in an ssh situation where we see the forwarded X display, but not the session bus. The D-Bus based menu exporting will not work in this situation.
See bug 741740 for the g-s-d patch that this was tested against.
Review of attachment 293016 [details] [review]: Probably would have been possible to avoid the goto;, but this looks fine (assuming the other part gets accepted). Good idea about avoiding the GetId call if the xsetting is missing.