Re:Libwsm: Wayland Security Module library for Wayland compo...
by chrismorgan on Monday July 19, 2021 @11:50AM
(#27883955)
That these issues occur demonstrates a problem in the Wayland ecosystem, whether with compositors or individual apps. Compositors are supposed to be interchangeable from apps’ perspectives.
I believe the problems listed with Firefox, Audacity and cq-editor would apply to any Wayland compositor. I will note that once you’ve done MOZ_ENABLE_WAYLAND=1, the remaining Firefox problems are likely to be significantly less obvious in a non-tiling, purely-client-side-decorations window manager. That doesn’t stop them from being bugs.
For the Krita one, in a high-DPI environment you’ll either need to use unsupported patches on XWayland and worry about QT_SCALE_FACTOR, or use the stable version and get a terrible result that will be nigh unusable for certain purposes (though normally you’ll just call it ugly and annoying); whereas if you use X right through, you can have proper high-DPI.
The Zoom crash, who knows; I certainly don’t, since they don’t make it easy to inspect what’s going wrong. There’s a good chance it’d work properly under at least GNOME.
For comparison, under i3 I don’t think I ever experienced general issues like these (that would apply to all WMs), and experienced WM-specific issues only a few times, minor and workaroundable each time.
The distinct impression I’m getting is one of immaturity. I’m still using it, because it does solve a couple of things that X didn’t do well that I consider moderately important, and more importantly because I’m an intrepid idiot willing to put up with a lot in the name of daily-driving the future to help iron it out for others. (As another such thing, Firefox Nightly has been my daily driver for just over a decade except for a cumulative total of about a year.)
I believe the problems listed with Firefox, Audacity and cq-editor would apply to any Wayland compositor. I will note that once you’ve done MOZ_ENABLE_WAYLAND=1, the remaining Firefox problems are likely to be significantly less obvious in a non-tiling, purely-client-side-decorations window manager. That doesn’t stop them from being bugs.
For the Krita one, in a high-DPI environment you’ll either need to use unsupported patches on XWayland and worry about QT_SCALE_FACTOR, or use the stable version and get a terrible result that will be nigh unusable for certain purposes (though normally you’ll just call it ugly and annoying); whereas if you use X right through, you can have proper high-DPI.
The Zoom crash, who knows; I certainly don’t, since they don’t make it easy to inspect what’s going wrong. There’s a good chance it’d work properly under at least GNOME.
For comparison, under i3 I don’t think I ever experienced general issues like these (that would apply to all WMs), and experienced WM-specific issues only a few times, minor and workaroundable each time.
The distinct impression I’m getting is one of immaturity. I’m still using it, because it does solve a couple of things that X didn’t do well that I consider moderately important, and more importantly because I’m an intrepid idiot willing to put up with a lot in the name of daily-driving the future to help iron it out for others. (As another such thing, Firefox Nightly has been my daily driver for just over a decade except for a cumulative total of about a year.)