On Fri, 2015-08-14 at 11:22 -0400, Ray Strode wrote: [ snip ]
> Still, I think this change is wrong headed. We've been trying to > cleave ourselves from environment variables for years in the default > case. Having to set this seems like a step backward. > This means having to jump through additional hoops when using systemd > --user sessions, it means > having to jump through an additional hoop when running a program from > a VT, and it means having > to jump through an additional hoop when ssh'ing in to debug > something. Agreed. Unfortunately i don't follow the list closely enough to spot this patch earlier. We've got several project/systems out there which do use the combination of weston and systemd user session, which will get broken with this behaviour change. Same for some of our automated testing which logs into boards over serial and ssh and relies on programs being able to connect to the default compositor without extra environment variables. > > if a user runs a program it should show up on the default display in > a > clean environment. save the environment variables for fringe cases > like nested compositors. > > The problem purportedly getting fixed gives this as a rationale: > > > Now suppose you launch Weston while running the Gnome session. > > Suddenly, all of the Gtk+ apps > > launched from Gnome will show up inside Weston instead. That's > > unexpected. There's also no good > > way to prevent that from happening (other than perhaps setting > > WAYLAND_DISPLAY to an invalid value > when launching an app). > It's wrong to say there's no good way to prevent programs from > launching on weston. This corner case, can be covered by setting the > GDK_BACKEND environment variable. edge cases should use environment > variables not the default case. The problem here is GDK_BACKEND would practically need to be set when launching the graphical session. Which e.g. gdm could easily do but you can't really rely on all display manager to do so. And ofcourse such environment variables would need to be set for each toolkit, which isn't great.. However a nicer/simple solution with weston would be to use e.g: weston -Snested-wayland Which will have the same effect as the committed patch (programs won't connect to the compositor without having WAYLAND_DISPLAY set). If the corner case this patch was supposed to fix is indeed that problematic potentially a better fix for that would be to have weston not use wayland-0 as the socket if it's running nested? > Furthermore, the commit says it's trying to fix a scenario where the > user is logged into X, but the commit actually breaks X logins > (because of the above log handler issue)! That means it wasn't > tested. > > I don't think the commit is good idea at all, can we revert it ? > XDG_RUNTIME_DIR is supposed to free us from other environment > variables. Indeed! Even recent dbus can use that these days for its user bus, seem s rather a shame wayland would go a step backwards here... > --Ray > _______________________________________________ > wayland-devel mailing list > wayland-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/wayland-devel -- Sjoerd Simons <sjoerd.sim...@collabora.co.uk> Collabora Ltd. _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel