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>
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>
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.
Signed-off-by: David Edmundson <davidedmundson@kde.org>
In some environments it is desirable to show an input panel UI (e.g. OSK)
that is able to perform miscellaneous actions other than inserting text.
Add the framework for this, the available actions may be extended in later
versions of the protocol.
Signed-off-by: Tadeo Kondrak <me@tadeo.ca>
This change makes it clear that there's an extra buffer for the value.
This explains the purpose of the complicated design.
Signed-off-by: Dorota Czaplejewicz
Currently, the after-effects of the set_cursor_rectangle request on
the input method UI and the client-side redraws are not guaranteed
to be atomic.
Add the requirement for compositors handling the newer version of
the protocol to make the set_cursor_rectangle request visually
effective with the same wl_surface.commit.
Signed-off-by: Tadeo Kondrak <me@tadeo.ca>
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>
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>
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>
Here's a long story. The serial is formerly described as:
When the client receives a done event with a serial different than the
number of past commit requests, it must proceed as normal, except it
should not change the current state of the zwp_text_input_v3 object.
Upon first reading it might be obvious to interpret "proceed as normal"
as "apply the changes made by the done event" and "not change the current
state" as "do not make requests on it until serial matches with
expectations again". This would turn the serial into a flow control
mechanism to avoid pushing state changes that we know might be stale.
GTK however makes another outlandish interpretation, where "proceed as
normal" means "ignore the changes made by the done event" and "not change
state of the zwp_text_input_v3 object" is "not change client state". This
makes the serial a full synchronization mechanism where IM commands that
are deemed out of sync are symply ignored.
This would seem a misinterpretation of the protocol, and I proceeded to
change the behavior in GTK. Then some deja vu feeling struck me and I found
https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/384#note_344864, this
change was already done and discussed in the past. Not just that, it is
the right interpretation.
However, there's some notable disadvantages, there's 2 easy ways to
completely break the synchronization between compositor and client:
Having the IM push new state too often (i.e. multiple consecutive
.done events), or having the client .commit too often. If any of both
peers gets ahead of the other slightly, the end result is ignored input.
More specifically, IBus has no provision for this kind of transactional
behavior (probably other IMs too), so implementing "emit .done once after
a set of changes" is not quite possible.
Arguably, ignoring IM input is also a bad thing. IMs expect all commands
to be respected and applied in order and might even rely on that in
their own internal state. Since only state changes are flushed on .done
events, partially ignoring IM commands will end up with the client IM state
out of sync.
The usecase described at that GNOME gitlab comment (edited text changes
happening in parallel to IM interaction) trades the handling of an
inherently racy corner case with the worst kind of mishandling (ignoring
user input) if IM/client don't perfectly sync up.
On the other hand, the flow control approach is more lenient with IMs and
clients "getting a step ahead", and more importantly does not punish the
user whenever either IM/client happens to do that. Double down on this
(already intuitively correct) description, and specify further what it
implies.
Signed-off-by: Carlos Garnacho <carlosg@gnome.org>
Currently protocol does not specify what should happen if multiple
text-inputs are created by same client, which is why this is more or
less undefined behavior currently in compositor implementations.
If client has created more than one text-input objects and surface owned
by the client is focused, then compositor must send enter event to all
text-input objects, in case of enable request however only one
text-input must be enabled per client per seat.
Signed-off-by: Bhushan Shah <bshah@kde.org>
This new protocol description is an evolution of v2.
- All pre-edit text styling is gone.
- Pre-edit cursor can span characters.
- No events regarding input panel (OSK) state nor covered rectangle.
Compositors are still free to handle situations where the keyboard
focus rectangle is covered by the input panel.
- No set_preferred_language request for clients.
- There is no event to send keysyms. Compositors can use wl_keyboard
interface instead.
- All state is double-buffered, with specified defaults.
- The compositor can be notified about external changes to the state.
- The client can detect outdated requests.
Signed-off-by: Dorota Czaplejewicz <dorota.czaplejewicz@puri.sm>
Signed-off-by: Carlos Garnacho <carlosg@gnome.org>
Reviewed-by: Jonas Ådahl <jadahl@gmail.com>
Reviewed-by: Simon Ser <contact@emersion.fr>
Interface names are lower_snake_case, and corresponding descriptions
should match, for accuracy and clarity. This renaming only affects
description text, to follow the convention that exists elswhere in
this protocol document and in other protocol docs, when referring to
interface names.
Signed-off-by: Yong Bakos <ybakos@humanoriented.com>
Reviewed-by: Bryce Harrington <bryce@osg.samsung.com>
Reviewed-by: Jonas Ådahl <jadahl@gmail.com>
Replace the tab indentation of the MIT license with appropriate spaces.
Add one missing line break between two description paragraphs.
Adjust two line breaks to keep descriptions under 80 chars / line.
Signed-off-by: Yong Bakos <ybakos@humanoriented.com>
Reviewed-by: Bryce Harrington <bryce@osg.samsung.com>
Reviewed-by: Jonas Ådahl <jadahl@gmail.com>
