| Age | Commit message (Collapse) | Author |
|---|
|
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>
|
|
Signed-off-by: onox <denkpadje@gmail.com>
|
|
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>
|
|
Signed-off-by: Yong Bakos <ybakos@humanoriented.com>
Reviewed-by: Bryce Harrington <bryce@osg.samsung.com>
Reviewed-by: Jonas Ådahl <jadahl@gmail.com>
|
|
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>
|
|
Signed-off-by: Bryce Harrington <bryce@osg.samsung.com>
Reviewed-by: Eric Engestrom <eric.engestrom@imgtec.com>
Reviewed-by: Yong Bakos <ybakos@humanoriented.com>
|
|
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
|
|
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
|
|
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
|
|
Renamed from "text" to "text-input" and applied the unstable naming
convention.
Signed-off-by: Jonas Ådahl <jadahl@gmail.com>
|
