[PATCH v4 wayland-protocols] text: Create second version of text input protocol

[Rui Tiago Cação Matos]

On Wed, Feb 17, 2016 at 6:13 AM, Jan Arne Petersen <janarne at gmail.com> wrote:
>>> +    <request name="set_cursor_rectangle">
...
>>> +      <arg name="x" type="int"/>
>>> +      <arg name="y" type="int"/>
>>> +      <arg name="width" type="int"/>
>>> +      <arg name="height" type="int"/>
>>
>> These arguments could, and perhaps should, all be type="uint"
>
> Yes I guess for width/height.

As Jonas pointed out, just leave them as "int". One thing I now
noticed is that the text says the coordinates are relative to the
surface but I think it's better to be explicit and use the main
wayland protocol terms "surface local coordinates" i.e. the
coordinates should take the surface scale into account.


>>> +    <request name="invoke_action">
...
> It is used to be able to interact with pre-edit text (move the cursor
> within pre-edit text or touch-and-hold to get some more options).

Aren't those client side operations? This request just doesn't seem
right in this protocol. Perhaps it belongs in a different protocol for
specific environments/devices? The text protocol should be strictly
about text input IMO.


>>> +    <event name="enter">
...
> Yes we have the text focus in cases there is no keyboard available
> (currently there is no way to have a focus then).
>
> It does not make sense to have text and keyboard focus on different
> surfaces at least not for the same seat. I do not see any case where you
> would want hardware keyboard input and virtual keyboard input going into
> different widgets/surfaces at the same time.

Perhaps it doesn't make sense but I don't see why we need to tie them
up here, just like wl_pointer's focus isn't necessarily tied to
wl_keyboard's focus in the main protocol.

In practice, sure, compositors will likely keep them all synced. In
any case, the sentence

"When the seat has one or more keyboards the text-input focus follows
the keyboard focus."

can't be worded like that because, again, even if a seat doesn't have
a hardware keyboard, the wl_keyboard object (and its focus) may exist
anyway. At least, it needs to be changed to

"The seat's text-input focus follows the keyboard focus."

if we indeed want to specify that they must be tied.

>>> +    <event name="modifiers_map">
>>> +    <event name="keysym">
...
> wl_keyboard currently does not allow to send synthetic key events when
> you want to just send keysyms.

Why do we need to send keysyms though? Isn't it enough to commit
(single character) strings?


Rui