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

[Jonas Ådahl]

On Thu, Feb 18, 2016 at 08:36:38PM +0100, 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.
> 
> 
> >>> +    <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?

One reason would be to match key presses without keycodes (such as when
they come from VNC or a hardware device outputting keysyms instead of
keycodes) with modifiers, so one can press Ctrl-Å. I suppose sending a
modifier keycode (assuming a keycode could represent the expected
modifier keysym given the keyboard layout), and let the client match
the current modifier state with single-character committed strings, but
that seems a bit like an abuse of what committed strings represent, i.e.
just changed content, not unlikely with unforseen consequences.


Jonas

> 
> 
> Rui
> _______________________________________________
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/wayland-devel