Hi, Am Dienstag, 9. März 2021, 11:17:31 CET schrieb Adrien Glauser:
Oups pressed the wrong button and the first part of my reply to Fabian was not CC'ed to the list:
8<--------------------------
Dear Fabian,
Thanks for your email, I appreciate.
I've checked out the thread you mention as a poll. I see only 1 reply there. Where can I see the other replies -- if possible those that specifically address the question, because you're asking two separate questions in that poll?
IIRC there were just three or so replies in total, none of which were against the "Xwayland" session. There weren't any bug reports about this either, and IIRC there still aren't. As a conclusion, the status quo was kept.
Who are the "testers" you refer me to? (Sorry I've been a member of oS since last summer, and I don't know who they are).
In that case I just meant anyone who does testing for this topic. What needs to be tested is whether the issues the "Xwayland" session works around are still present and to which extent. The easiest way to do that is by using the "Full Wayland" session instead. So everyone using "Plasma (Wayland)" should try "Plasma (Full Wayland)" and report issues.
And again, isn't asking for their feedback replaying the same issue (i.e. bias control) in a different context?
There's always bias to some extent, but there's a world of difference between "X is great" and "Please try out Y", if the goal is to collect plain data.
Finally did you apply the same measures for extracting unbiased feedback when you or your predecessor introduced this patching?
It was never actively introduced, it was the upstream default in Qt until 5.9 (IIRC). When Qt 5.9 with the change arrived in TW, there were some bug reports and mails about this, so we simply decided to revert the change and keep the old default for longer. Cheers, Fabian
Cheers,
Adrien
Le 09/03/2021 à 10:35, Fabian Vogt a écrit :
Hi,
there are some misunderstandings and misconceptions in this mail and the replies. I don't have the time to clear those up in depth right now, so I hope that there's enough info in this thread: https://lists.opensuse.org/archives/list/kde@lists.opensuse.org/message/BIWK... It's a link to a poll on this topic from half a year ago on [os-kde], where I also explained the background.
tl;dr: It exists for an easier transition to using Plasma with Wayland, to work around certain shortcomings (middle-click paste, application interop) and bugs (KMail/WebEngine on Wayland. If those shortcomings are no longer there or no longer relevant to the target group (recent/current users of the X11 sessions), then the deviation from upstream defaults served their purpose and can be retired.
Input from users is needed for that, to ensure that it doesn't introduce any regressions which force them away from the Wayland sessions again.
The alternative is to do a scream test: Switch the defaults and see whether someone complains.
I'm not opposed to either of those and would prefer a combination: Ask for feedback from testers, and if it's not enough, do the scream test. I'm more than happy to drop this, if it's the right time.
Am Montag, 8. März 2021, 11:08:59 CET schrieb Adrien Glauser:
Dear all,
Over the past months I've run into multiple bugs on both "wayland sessions" shipped by default by Tumbleweed (Leap uses the same settings so it's in the same boat as far as I can tell) which I was never running into on two other Linux distributions (i.e. NixOS and Fedora). This caught my attention and after back and forth discussions with Plasma developers and members of the oS community, this conclusion has become inescapable: most of these bugs are not just facilitated, but outright *caused* by certain settings that the package maintainer(s) of the Plasma desktop have decided to apply, against the recommendations of the Plasma developers.
It has to be noted that "package maintainers" and "Plasma developers" are not two disjoined groups.
The Qt Wayland QPA has known issues, and it actually disables itself by default in a GNOME session for those reasons and uses xcb instead.
If like me a couple of days ago you aren't familiar with this topic, the issue revolves around two environmental variables which our Plasma packagers have decided to override: - GDK_BACKEND: our xwayland session (displayed as "Plasma Wayland" in SDDM) is built with a patch overriding its value to "xcb", while our wayland session (displayed as "Plasma Full Wayland in SDDM) overrides it to "wayland" - QT_QPA_PLATFORM: overriden to "xcb;wayland" and "wayland;xcb" in the two sessions respectively.
The "Plasma (Wayland)" session does not override QT_QPA_PLATFORM.
Both variables are read at runtime to control the choice of a display client by GTK and Qt apps, as their name suggests. In this instance our xwayland session forces GTK apps to use an X11 client, whereas our wayland ("Full Wayland") session forces them to use a Wayland client. As for Qt apps, xwayland forces them to use an X11 client -- with a fallback on a wayland client -- while wayland ("Full Wayland") does things vice-versa -- forces them to use a wayland client, with a fallback on X11.
Now for the issue: roughly put, the issue is that the decision to override these values corners users in an impossible dilemma. To appreciate the dilemma, we can consider two widely used sets of applications: a. recent, well-maintained Qt/GKT native applications installed from official .RPM packages (typically: Kate, Konsole, Kwin); and b. flatpak-ed, apps using either slightly outdated GTK libraries or based on the Electron stack (~ most of the flatpaks)
If the user picks xwayland, several apps in (a) will run into issues. The reason is that KDE developers, in the course of migrating their code base to the wayland compositing protocol, have made substantial efforts to make these applications play nice with a wayland client, and pushing these applications in the reverse direction is likely to introduce regressions, to escape test coverage and make it very, very difficult for the end user to get troubleshooting and support from KDE. While if the user picks wayland ("Full Wayland"), the (a)-applications will run fine but the (b)-applications will be very buggy, and most of them will just refuse to launch.
And by the way it's very easy for you to test both horns of the dilemma. That's simply a cherry-picked example, but it's not difficult to come up with more: try making a custom, rectangular capture using Spectacle in xwayland (this will fail because the program was built with the idea that it would output to wayland, not X11); or try launching something like the OBS Studio flatpak in wayland ("Full Wayland").
Until yesterday I thought that the solution to this pain was to use a different choice of values for GDK_BACKEND and QT_QPA_PLATFORM, setting them for example to "xcb" and "wayland;xcb", building on the assumption that Qt apps need wayland and that Gtk apps are compatible with X11. But in fact we don't *need* at all to find any particular combination of values, because as other members of the community pointed out, both Gtk and Qt apps are perfectly able to find their way to their preferred display client. So the best course of action is simply to not force any particular value down their throat, which as far as I know boils down to simply removing the xwayland and wayland ("Full wayland") sessions, replacing them with a session in line with upstream, which does not bake these values into their plasma desktop builds.
To me the situation can be summarized by: we're altering the plasma desktop from upstream, sending to library and application developers a message that is more or less "we don't care what you guys think your programs should display to, because we at oS know better". This message would be tolerable if it secured the best for our users, but as I've tried to suggest, that's not the case. Not only are our users going to have a flawed perception of the Plasma desktop, because it behaves too rogue to express the intent of upstream, but we are making it unnecessarily difficult for our users to get decent troubleshooting, because no other distribution does it our way. That means a much smaller user pool to draw from when troubleshooting our users, and requires that our users remember to warn people at bugs triage that they're using a *special plasma config*.
I've reached out yesterday to Fabian Vogt -- one of the maintainers of our plasma desktop package -- on these matters, and so far he has been helpful and open-minded. I certainly don't want to arm-wrestle him over this mailing list. Instead I am trying to fulfill his demand for more user feedback.
The right way to do that is by asking in an "unbiased" mail, because only then replies can be based on an informed decision. This mail doesn't fit that criteria unfortunately. It also omits the reasons why this split between the two Wayland session types was introduced in the first place.
Cheers, Fabian
Best,
Adrien