Am Sonntag, 9. Mai 2021, 22:59:35 CEST schrieb Andrés Barrantes Silman:
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
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:
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
For me, the fact that Vivaldi, VS Codium and Element were working without touching
Ah, so probably GDK_BACKEND=wayland.
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.