https://bugs.kde.org/show_bug.cgi?id=405388
Bug ID: 405388
Summary: Virtual keyboard implementation forces compositor-side
input method handling on wayland clients
Product: kwin
Version: unspecified
Platform: Other
OS: Linux
Status: REPORTED
Severity: normal
Priority: NOR
Component: virtual-keyboard
Assignee: kwin-bugs-n...@kde.org
Reporter: gatis.paeg...@qt.io
Target Milestone: ---
SUMMARY
Virtual keyboard implementation (via text_input extension) forces
compositor-side input method handling on wayland clients, without offering
other input methods at compositor side, e.g. ibus or compose. Plasma UI offers
to disable virtual keyboard, from which I assumed that it disables text_input
extension at the compositor (but it doesn't), so clients can use text composing
at client-side in this case. Here is a work-in-progress patch
https://codereview.qt-project.org/#/c/248181/ for Qt, which detects that
text-input extension has been unloaded and hence should fallback to the normal
QT_IM_MODULE handling at client-side (see reconfigureInputContext()). What kwin
does instead is (see m_enabled):
void VirtualKeyboard::show()
{
if (m_inputWindow.isNull() || !m_enabled) {
return;
}
m_inputWindow->setGeometry(screens()->geometry(screens()->current()));
qApp->inputMethod()->show();
}
The author clearly did not think about supporting other input methods when
keyboard is "disabled". And did not provide a way to really disable it. From
clients points of view it is never disabled. Clients do not get any messages
when clicking on enable/disable vkb.
text_input extension means that compositor claims that it will handle all
keyboard input composing at compositor side, but kwin's implementation cares
only about virtual keyboard. This means that compose key (dead key) sequences
will not work, and ibus for e.g. Chinese input also won't work, even though
compositor claims that it will handle everything. If compositor instead would
unload the extension when user selects to disable vkb support from the menu,
then Qt could fallback to handling 'ibus', 'compose' *or any other input method
which supports QT_IM_MODULE) at client-side.
QT_IM_MODULE is unset on default KDE neon env. When unset, and if compositor
claims to support text-input, then Qt won't do any text composing locally. If
Qt application is started with QT_IM_MODULE set to something, then Qt will use
that input method instead. Setting QT_IM_MODULE to 'compose' is the current
workaround for enabling compose keys, but will disable vkb support in that
application.
Other solution is that Kwin should add not only an option to disable vkb, but
also a way to switch from vkb to ibus for example. Then it can keep text_input
always loaded, just switch input methods at compositor-side.
Addition details:
qtwayland:
commit 5444ea50bb2b1b894d5b3c33676f9ef207fdcd1a
Author: Jan Arne Petersen <jan.peter...@kdab.com>
Date: Wed Dec 30 00:08:17 2015 +0100
Fix text-input support for new API
Update text input support to upstream text-input protocol v2 from
wayland-protocols. Remove support for input-method protocol for now.
Map text-input protocol on compositor side to the Qt input method API,
this allows to use any qt platform input method on compositor side
(especially qtvirtualkeyboard). Add support for qtvirtualkeyboard to
pure-qml example.
Implement all missing functions of the text-input protocol.
Change-Id: I597451ff65454a63dff86026b6a8d1ffbe07ce02
Done-with: Zeno Endemann <zeno.endem...@kdab.com>
Reviewed-by: Giulio Camuffo <giulio.camu...@kdab.com>
=========================================
kwin:
commit f26f2fe181ae0500a9105ad0864d1f3062d0d30c
Author: Martin Gräßlin <mgraess...@kde.org>
Date: Fri Apr 29 15:05:03 2016 +0200
Integrate QtVirtualKeyboard into KWin/Wayland
Summary:
The idea is to have KWin provide a virtual keyboard. To support this
KWin uses the QT_IM_MODULE qtvirtualkeyboard and makes sure that the
QPA plugin loads it.
KWin has a new class VirtualKeyboard which acts as the focus object and
the "proxy" for input methods. The QPA plugin ensures that this is the
focusObject, so that all input method related events are sent to this
class. From there it will be possible to delegate to other applications
through the Wayland interfaces.
==========================================
So on Dec, 2015 Qt project added support for "any qt platform input method on
compositor side" (see QWaylandTextInput), while few months later (Apr, 2016)
KDE added a less complete solution to KWin. KWin supports only a vkb at
compositor side, because they map IM APIs to wayland wire inside
virtualkeyboard.cpp, without any generalization (see
https://phabricator.kde.org/R108:f26f2fe181ae0500a9105ad0864d1f3062d0d30c)
text_input_2 protocol is for any input method handling at compositor-side, it
is not virtual-keyboard-only protocol. Furthermore, upstream even has removed
any vkb support from text_input_v3 (which is a topic for discussion on its own)
and some individual is working on a dedicated protocol for vkb handling.
The main point is - KWin compositor needs fixing.
--
You are receiving this mail because:
You are watching all bug changes.
