text-input: update to 3.2
- Nov 11, 2024
-
-
Carlos Garnacho authored
There seems to be some demand from input methods to be able to style different parts of the preedit string differently. Since the reasons to do that are many, and vary between IMs and languages. But even though some IMs would much want to be able to specify colors, they lack the context to know what choice of colors provides enough contrast and legibility embedded on foreign UIs (e.g. accounting things like themes, accessibility, ...). There is a proposal for a semantic closed list of pre-edit styling options at https://github.com/ibus/ibus/wiki/Wayland-Colors , which this commit follows, so clients and UIs have more freedom in displaying a suitable style to pre-edit strings. Signed-off-by: Carlos Garnacho <carlosg@gnome.org>
286be709
-
- Oct 30, 2024
-
-
Carlos Garnacho authored
These requests allow clients to explicitly declare the desired interaction pattern with input panels (e.g. the system OSK). This allows clients to decide a fine grained pattern to show/hide these panels that is decouple of enable/disable requests. This may help them enhance the experience with e.g. selecting text, or navigating around large bodies of text without an intrusive OSK, or implementing other UI patterns like a "show OSK" button. Signed-off-by: Carlos Garnacho <carlosg@gnome.org>
d4a4aa82 -
Some input methods such as a virtual keyboard allow a user to switch between different languages. This is important to clients as some languages should be rendered as RTL or change font rendering.
1e04ae45 -
Signed-off-by: Tadeo Kondrak <me@tadeo.ca>
fa81000e -
Signed-off-by: Tadeo Kondrak <me@tadeo.ca>
7d21ecb9 -
Some clients don't show preedit text inline, so the compositor may want to display the preedit text in a popup window instead. Signed-off-by: Tadeo Kondrak <me@tadeo.ca>
5323b0f3 -
Allow hinting input methods about if Emoji support is not useful for special applications likes IDE, which manage or debug other applications. Fixes: #79 Signed-off-by: fujiwarat <takao.fujiwara1@gmail.com>
1dd156d8 -
The new hint is meant to indicate that the text input already provides an on-screen means to enter data, and that using the system provided input method may not be needed. It should be used when the client presents the user with a custom on-screen input method, like an on-screen keyboard, or perhaps a dropdown list. The new hint is meant to address the issue when the system input method is an on-screen keyboard. Without the hint, the input method would not know that it's not needed, unless the client refrained from using the input method protocol at all. With the hint, the input method can still be enabled, while not displaying a second on-screen keyboard. This allows for the system input method to still provide accessibility services, as well as text completion or prediction. Based on discussion in https://gitlab.gnome.org/GNOME/gtk/merge_requests/978 Signed-off-by: Dorota Czaplejewicz <dorota.czaplejewicz@puri.sm>
c357a0d5
-