Hi Jonas, > > > I would prefer leaning towards just making the compositors more > > > considerate about their Xwayland configuration. I believe the global > > > trend is to move towards the compositor having all the configurability > > > in itself, and all the other components having a single source of > > > configuration in the running system: the compositor. I would compare > > > Xwayland to libinput here. > > > > Yes, but that means that all compositors need to have this > > "configurability", even though it's actually Xwayland that uses it. > > > > For a compositor that supports respawning Xwayland, to be able to change > the Xwayland configurations without restarting the actual compositor > would still need this "configurability", as any user set environment > variable will be static for the whole session.
Obviously, with a compositor able to survive respawning Xwayland, adapting the Xwayland command line options dynamically when it detects a crash in Xwayland, the use of environment variable is a lot less attractive. But I am not aware of any compositor able to do that (and given how mutter is dependent on X even on Wayland, I would not expect such a mechanism to be available in gnome-shell any time soon). Cheers, Olivier _______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
