Apps_Issues issueshttps://source.puri.sm/Librem5/Apps_Issues/-/issues2018-08-27T15:53:40Zhttps://source.puri.sm/Librem5/Apps_Issues/-/issues/54Keyboard preedit text inconsistent2018-08-27T15:53:40ZDorota CzaplejewiczKeyboard preedit text inconsistent# What application is this relating to?
The issue is not specific to any particular project, or at least the project needs to be determined.
# What problem did you encounter
Odd behaviour where previous text is sticking to the cursor ...# What application is this relating to?
The issue is not specific to any particular project, or at least the project needs to be determined.
# What problem did you encounter
Odd behaviour where previous text is sticking to the cursor until new preedit text is entered.
GTK stores preedit text in text fields, similar to selection. The preedit contents stay inside the text field even if it loses focus and regains it again.
The text-input-v3 protocol has no facility to notify the compositor about already present preedit text. This causes previously described odd effects.
There are 2 solutions, which describe different models of behaviour:
- preedit doesn't exist in unfocused widgets. Client libraries would need to be adjusted
- preedit is persistent and gets sent to the compositor. The *protocol* would need to be adjusted.
This might be an important detail for CJK input methods, where considerable work goes into composing a preedit text.
Needs discussing with the usual people who review input method-related protocols: wlroots, Carlos, Eike.A1: Support fully featured on screen keyboardDorota CzaplejewiczDorota Czaplejewiczhttps://source.puri.sm/Librem5/Apps_Issues/-/issues/16need to port/create: on-screen keyboard2019-10-11T12:51:08ZDorota Czaplejewiczneed to port/create: on-screen keyboardKeyboard used currently and the one likely to be provided on the devboards is *weston-keyboard*. It does its job, but it's rather unsuitable for a phone.
We need a design which is easier to modify and prettier, with support for multip...Keyboard used currently and the one likely to be provided on the devboards is *weston-keyboard*. It does its job, but it's rather unsuitable for a phone.
We need a design which is easier to modify and prettier, with support for multiple languages, ideally written in GTK3.
A possible solution is [eekboard](https://github.com/ueno/eekboard/), which is already GTK3, but has a rather unnecessary server-client DBus interface, and is not aware of Wayland input method.A1: Support fully featured on screen keyboardDorota CzaplejewiczDorota Czaplejewicz