[PATCH wayland-protocols] text: Create second version of text input protocol
Bill Spitzak
spitzak at gmail.com
Wed Feb 3 01:59:11 UTC 2016
On Tue, Feb 2, 2016 at 4:58 AM, Jan Arne Petersen <janarne at gmail.com> wrote:
>
>
> On 29/01/16 00:33, Bill Spitzak wrote:
> >
> >
> > On Wed, Jan 27, 2016 at 11:52 PM, Jan Arne Petersen <janarne at gmail.com
> > <mailto:janarne at gmail.com>> wrote:
> >
> >
> > + Text is generally UTF-8 encoded, indices and lengths are in
> > bytes.
> >
> >
> > Remove the word "generally". *All* text in your api's are UTF-8.
>
> Done
>
> > + <request name="activate">
> > + <description summary="request activation">
> > + Requests to activate a surface for text input (typically
> when a
> > + text entry in it gets focus).
> > +
> > + There can only be one active surface per client and seat.
> > When surface is
> > + null all surfaces of the client get deactivated.
> > + </description>
> >
> >
> > I think clients should be allowed to send activate more than once per
> > surface, it is to indicate the input focus switching between widgets.
> > This removes the need for another api to indicate the widget is
> > switching. Sending null for the surface, or a different event, would
> > indicate that the keyboard focus is no longer on a text input widget.
>
> We use enable/disable request now. That should be a bit easier to handle
> from client side.
>
> > + <request name="reset">
> > + <description summary="reset">
> > + Should be called by an editor widget when the input state
> > should be
> > + reset, for example after the text was changed outside of the
> > normal
> > + input method flow.
> > + </description>
> > + </request>
> >
> >
> > I believe this request can be replaced by redundant activate requests.
>
> It got integrated into update_state.
>
> > + <request name="set_surrounding_text">
> > + <description summary="sets the surrounding text">
> > + Sets the plain surrounding text around the input position.
> > Text is
> > + UTF-8 encoded. Cursor is the byte offset within the
> > + surrounding text. Anchor is the byte offset of the
> > + selection anchor within the surrounding text. If there is no
> > selected
> > + text anchor is the same as cursor.
> > + </description>
> > + <arg name="text" type="string"/>
> > + <arg name="cursor" type="uint"/>
> > + <arg name="anchor" type="uint"/>
> > + </request>
> >
> >
> > The anchor could be very far away from the cursor, much farther than any
> > small limit on the request size. I think this means the anchor position
> > could be negative or larger than the text length. Sending this without
> > clamping would be a good idea, the input method would then have a hint
> > where the anchor is, and it can clamp the value itself.
> >
> > If the client wants new text to replace the selected text, the text
> > between anchor+cursor will be deleted, and any input method decisions
> > would depend on the text outside the anchor..cursor range. This may be
> > larger than the allowed buffer size, so I think clients have to send the
> > text as though the selection was deleted.
> >
> > A client that does not want to replace the selected text could still
> > send an anchor, but then I am not clear if the input method can take
> > advantage of knowing what characters are selected to modify the results.
> > So it is possible the anchor is not needed at all.
>
> Ok I use an int for anchor now. It still make sense for an input method
> to know what is in the selection even when it gets replaced by new
> entered text.
>
I am unclear whether it is the input method's job to decide whether
characters replace the selection, or the client's job.
My concern is this:
- The input method has rules so that if the text before the cursor is "A"
and the user types 'x', you get "Ay". If the text is any other letter such
as "C" you get "Cx".
- Assume the text before the cursor is "Annnnnnnnn" where all the 'n' are
selected, and the length of the selection exceeds the size allowed by the
surrounding text request. Therefore the input method cannot know there is
an 'A' there.
- The user types 'x'. The input method cannot be aware that there is an A
there and the result will be "Ax", not the correct "Ay".
My proposed solution is that the client decides whether input replaces the
selection or is appended to it. If it replaces the selection, the text it
sends the input method is with the selection already deleted.
Other solution is that the above situation does not happen in real input
methods.
>
> > I think you might want non-zero bits to *disable* features. This allows
> > zero to be the default, and means that if some new correction is
> > invented in the future then they can default to on without you having to
> > modify the numerical value of default.
>
> Toolkits need to handle default on client side now.
>
I'm concerned that the value of "default" should not change. Assuming most
toolkits choose default, it should not vary depending on when the toolkit
was compiled.
> Yes you do not want to show already typed text on a virtual keyboard in
> a password field. Usually the keyboard would show nothing then, no
> reason to show dots/stars on the virtual keyboard.
>
I would assume it is considered better to use preedit than to have a
virtual keyboard with it's own display, but I guess this is useful if
somebody insists on making the keyboard work that way.
> + <request name="invoke_action">
> > + <arg name="button" type="uint"/>
> > + <arg name="index" type="uint"/>
> > + </request>
> >
> >
> > Missing documentation? I would guess this is how clients send the
> > keyboard events to the input method?
>
> Added description. It is about clicking/touching within the
> composing/pre-edit text.
>
Makes sense. I think this could also be used to invoke the spelling
corrector if the user clicks in previous incorrect text.
> Added more description to v3:
>
> default: "default style for composing text"
> none: "composing text should be shown the same as non-composing text"
> active: "composing text might be bold"
> inactive: "composing text might be cursive"
> highlight: "composing text might have a different background color"
> underline: "composing text might be underlined"
> selection: "composing text should be shown the same as selected text"
> incorrect: "composing text might be underlined with a red wavy line"
>
I think I asked the question a bit wrong. The input method may be relying
on the user being able to distinguish two different highlights, and this
assumption would fail if a client renders them the same. Are there any
pairs of these numbers the client is allowed to render the same (for
instance default and none, can they be rendered identically?).
> > Can more than one of these be applied to the same bytes? If so, are they
> > allowed to intersect arbitrarily? I think it is reasonable to require
> > the input method to require any ranges to be entirely inside or outside
> > each previously-sent ranges. This makes it easier for a client to
> > mindlessly insert <b> and </b> tags into pango input.
>
> It might make sense to combine some so I do not want to exclude that.
>
Yes I agree combining them is required. My question is whether the input
method should be restricted to simple nesting. For instance if it wants a
region of active that intersects a region of highlight, it is not allowed
to do this:
active range = 1..5
highlight range = 3..7
Instead it must do this, so the highlight ranges do not cross previous
boundaries:
active range = 1..5
highlight range = 3..5
highlight range = 6..7
I believe if clients are allowed to assume this it will make their job
easier.
> + <event name="keysym">
> > + <description summary="keysym">
> > + Notify when a key event was sent. Key events should not be
> used
> > + for normal text input operations, which should be done with
> > + commit_string, delete_surrounding_text, etc. The key event
> > follows
> > + the wl_keyboard key event convention. Sym is a XKB keysym,
> > state a
> > + wl_keyboard key_state. Modifiers are a mask for effective
> > modifiers
> > + (where the modifier indices are set by the modifiers_map
> event)
> > + </description>
> > + <arg name="serial" type="uint" summary="serial of the latest
> > known text input state"/>
> > + <arg name="time" type="uint"/>
> > + <arg name="sym" type="uint"/>
> > + <arg name="state" type="uint"/>
> > + <arg name="modifiers" type="uint"/>
> > + </event>
> >
> > Is this for keysyms that the input method did not handle? Or for fake
> > key strokes? Or both?
>
> For synthetic key events (fake stroke) for unhandled real hardware key
> events wl_keyboard should be used (keyboard focus is the same as text
> focus).
>
How does the compositor prevent wl_keyboard events it used from being sent
to the client? What if the input method wants to handle the 'x' key itself,
but send the 'xy' combination to the client? It will have to eat the x-down
event, and then send a fake one just before the y-down???
I figured the input method would get all the keyboard events and would call
this with unhandled keystrokes.
I personally feel that Wayland will need to add an api that is more like
this, rather than clients running libxkb. It would solve all these
problems, and also make it far easier on remote desktop clients on systems
where you cannot get the keystrokes except in already-cooked form, and for
utilities that insert fake keystrokes. However I have been repeatedly told
that this is "impossible", for some reason having to do with multiple
keymaps (??). If you are able to get this in, then good for you. First step
toward fixing this.
Yes that is more for use cases like you switch the input method in while
> a text field is focussed and the new input method needs the state.
> (Else we would need to cache state on compositor side which I do not like)
>
This seems reasonable. It is trivial for a client to send the surrounding
text an extra time.
To prevent the client from sending surround text requests that are ignored,
I guess the input method should send a configure indicating that no text is
needed, then change it just before sending this event.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20160202/939a6fb5/attachment-0001.html>
More information about the wayland-devel
mailing list