[prev in list] [next in list] [prev in thread] [next in thread] 

List:       opensuse-factory
Subject:    Re: Please remove the xwayland ("Wayland") and wayland ("Full Wayland") sessions as we know them
From:       Fabian Vogt <fvogt () suse ! de>
Date:       2021-05-16 19:20:44
Message-ID: 11515494.8YQfmhk6dP () linux-e202 ! suse ! de
[Download RAW message or body]

Hi,

Am Sonntag, 9. Mai 2021, 22:59:35 CEST schrieb Andrés Barrantes Silman:
> > That is strange, because the "Full Wayland" session for both is identical (or at \
> > least supposed to be). The only difference is that "differentxwl" still offers \
> > the "XWayland" session, but by patching Qt (which isn't great).
> 
> Apparently it had to do with how the enviroment variables were ordered: if \
> GDK_BACKEND was set to "x11,wayland" it preferred x11, but if it was "wayland ,x11" \
> it went for wayland. 
> > Do you have a link to the upstream reports or have a backtrace?
> 
> No, sorry. I could try to troubleshoot a little bit but lack time right now.
> 
> > Is this using the compose key or just plain dead keys as part of the keyboard \
> > layout?
> 
> Compose key - this was fixed recently:
> https://bugs.kde.org/show_bug.cgi?id=411729
> https://bugreports.qt.io/browse/QTBUG-87088

Apparently qtwayland had compose key support for a while and it was removed
again, but now reintroduced... I submitted qtwayland with the latest changes
from the kde patch collection, which includes this fix.

> > What made the biggest difference?
> 
> For me, the fact that Vivaldi, VS Codium and Element were working without touching \
> enviroment variables.

Ah, so probably GDK_BACKEND=wayland.

> > change the default in qtbase to "wayland;xcb" and drop the "XWayland" session
> 
> In the case of GDK_BACKEND, what would happen?

If the concept of having separate sessions for "app compatibility" and
"wayland features" is dropped, then setting QT_QPA_PLATFORM and GDK_BACKEND
has to be dropped as well.

Now with Plasma 5.22 around the corner and the Beta already in KDE:Frameworks5,
I'm wondering about the timing of this change. While it might make sense to do
this together with the 5.22 update, IMO it's also not great to have too many
changes at once. Should this be postponed to around ~5.22.1 time?

The TW submission process doesn't easily allow testing 5.22 in parallel with
submitting the change to plasma5-workspace-5.21.5.

Cheers,
Fabian


[prev in list] [next in list] [prev in thread] [next in thread]