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:
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,
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
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
Finally did you apply the same measures for extracting
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.
> 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
> > that there's enough info in this thread:
> > It's a link to a poll on this topic from half a year ago on [os-kde], where
> > 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
> > 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
> > 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
> >> so it's in the same boat as far as I can tell) which I was never
> >> 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,
> >> issue revolves around two environmental variables which our Plasma
> >> packagers have decided to override:
> >> - GDK_BACKEND: our xwayland session (displayed as "Plasma Wayland"
> >> SDDM) is built with a patch overriding its value to "xcb", while
> >> wayland session (displayed as "Plasma Full Wayland in SDDM) overrides
> >> 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
> >> for Qt apps, xwayland forces them to use an X11 client -- with a
> >> fallback on a wayland client -- while wayland ("Full Wayland")
> >> 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
> >> 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
> >> That's simply a cherry-picked example, but it's not difficult to
> >> 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
> >> 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")
> >> 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
> >> programs should display to, because we at oS know better". This
> >> 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
> >> 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
> > 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