On Wed, Feb 17, 2016 at 6:13 AM, Jan Arne Petersen <jana...@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 _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel