Details
-
Task
-
Resolution: Fixed
-
P2: Important
-
None
-
1652687d3 (dev), 11456b4d5 (6.6), 2aebbfc9f (tqtc/lts-6.2), 5df751774 (6.5), c0d108b50 (dev)
Description
Proof of concept: [1]
Issues with the current implementation of QWaylandSeat::sendKeyEvent():
a) Cannot send letters from different alphabets without switching a layout (unless the keymap consists of many layouts? which would not be very usable API any way).
b) Sending unicode values does not seem to work (does not send ARABIC DIGIT THREE even when layout is set to "ar"). I did not investigate why this does not work:
waylandCompositor.defaultSeat.sendKeyEvent(0x0663, true); // ٣
c) No way to send capital latter?
d) Qt.Key_A is sent as lower case char, but ASCII value for Qt.Key_A is upper case
None of these problems are present in [1].
The solution from [1] relies on text-input extension. Sending virtual key presses via "defaultSeat.sendKeyEvent" conceptually is similar to using a virtual keyboard. For virtual keyboard to work, wayland clients need to support text-input extension, thus API users shouldn't see text-input as unreasonable requirement for "defaultSeat.sendKeyEvent" API.
It is not trivial to implement text-input support at client side. It might be enough to implement only the the the zwp_text_input_v2_keysym() handler at client side, but that would be really hackish.
Other solution could be to extend wayland core protocol:
wl_keyboard should add new wl_keyboard_keymap_format, e.g. something like: WL_KEYBOARD_KEYMAP_FORMAT_KEYSYM
Attachments
Issue Links
- relates to
-
QTBUG-62102 QKeySequenceEdit handles meta keys incorrectly on Wayland
- Closed
-
QTBUG-113387 API to construct a proper key event for a specific key/character
- Closed