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 <[email protected]> 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 > [email protected] > https://lists.freedesktop.org/mailman/listinfo/wayland-devel _______________________________________________ wayland-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/wayland-devel
