https://bugs.kde.org/show_bug.cgi?id=411729
Aleix Pol <aleix...@kde.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |aleix...@kde.org
--- Comment #32 from Aleix Pol <aleix...@kde.org> ---
So I looked a bit into the issue because I find it very frustrating. Here's
what happened:
1. it didn't work
2. Johan@Qt added the composite support:
https://codereview.qt-project.org/c/qt/qtwayland/+/211478
This worked like we expect to, at least to some extent since Johan@Qt did
mention there was some TODOs.
3. Gatis@Qt created a task that basically reverted Johan@Qt's work because
there was too much duplicated code (?). He created an issue in their bug
tracking system and then he "fixed it".
https://bugreports.qt.io/browse/QTBUG-65503
https://codereview.qt-project.org/c/qt/qtwayland/+/248181
---
To understand his suggestion we need to see how this is implemented in Qt:
There's two QT_IM_MODULEs at play here: QComposeInputContext (compose, in
QtBase) and QWaylandTextInput. They both inherit QPlatformInputContext.
QComposeInputContext is a small module that filters inputs and when there's a
compose key, it records it and filters the next one if it applies.
QWaylandTextInput is an implementation of the text-input-v2 protocol. This one
is what we use for talking to virtual keyboards.
As far as I understood, Gatis@Qt stance was that supporting both composition
and virtual keyboards at the same time is wrong for a series of things (see his
gerrit MR). His solution was to just remove composition and then blame KDE for
not supporting it in a different way:
https://bugs.kde.org/show_bug.cgi?id=405388
The different way he suggests is, if I understand correctly, that we activate
and deactivate the text_input_v2 offer depending on whether we have a running
keyboard: If there's a virtual keyboard offer, then kwin announces
text_input_v2, then the clients use QWaylandTextInput. When kwin considers that
a keyboard is what makes sense, it unregisters text_input_v2 and Qt clients all
switch to QComposeInputContext.
It's worth noting that the fact that these work at all on weston/sway/gnome is
pure chance: Qt implements a non-standard text input protocol so it always
falls back to QComposeInputContext.
---
My opinion and a plan:
I don't think that registering and unregistering will solve much and it feels
like we are workarounding a limitation from the compositor. In the end it's Qt
clients behaving weird exclusively (weston-terminal or gedit work just fine).
That said, Gatis@Qt did have some concerns with how it was implemented and I
don't think he was entirely wrong about these. I have the feeling that moving
the composition implementation from QWaylandInputDevice where Johan@Qt
initially implemented it to QWaylandTextInput (by copying some
QComposeInputContext code I guess) would work and allow us to move past this
weird situation. We wouldn't have though the problem of input methods fighting
one another since we'd already be in one of the implementations.
I'll think about it a bit further and see if I can just implement something to
get us out of this situation.
--
You are receiving this mail because:
You are watching all bug changes.
