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

[Jan Arne Petersen]

Hi,

On 18/02/16 20:36, Rui Tiago Cação Matos wrote:
> 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.

Ok I will do.

>>>> +    <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.

Yes we can just leave that out for now. I will remove it from the protocol.

>>>> +    <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.

Well pointer focus and keyboard focus are usually not in sync (pointer
focus is on the surface where the pointer currently is over, keyboard
focus where the keyboard input happens).

I do not know any toolkit supporting an extra text input focus beside
the keyboard focus. The current problem is the case when there is no
keyboard/wl_keyboard present in a wl_seat and then they do not have a
way to get a keyboard/text-input focus at all.

When we specify it is always the same as the keyboard focus, the
toolkits can easily use it for there text input/keyboard focus.

If you really want an extra independent text input focus that should
probably just be in an extra seat, which is of course also allowed from
this 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

That is coming from wl_seat documentation of the keyboard capability:
"The seat has one or more keyboards", I can of course also write "When
the seat has the keyboard capability the seat's text-input ..."

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

That is even better.

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

Yes I really want to specify that, so clients/toolkits can rely on that

>>>> +    <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?

There is also things like backspace, cursor keys and escape (or
something like ctrl-c for a terminal) which you want to input in a
virtual keyboard and which can not be represented as text commits.

Thanks for the feedback. I will prepare an updated v5 soon.
Jan Arne

-- 
Jan Arne Petersen | jan.petersen at kdab.com | Senior Software Engineer
KDAB (Deutschland) GmbH&Co KG, a KDAB Group company
Tel: +49-30-521325470
KDAB - The Qt Experts