Keysym event in the text protocol

[Daniel Stone]

Since you're just repeating yourself without taking on anything that's been
said, so will I: that won't work.

On Friday, July 25, 2014, Bill Spitzak <spitzak at gmail.com> wrote:

> I think the question is why both the client, the input method, and
> probably the compositor all have to do the decoding from keys to keysyms.
>
> Contrast this to all the work being done with libinput to translate
> actions on touchpads to a more useful shared form before anybody looks at
> it. Why is this not being done by clients, with them getting raw events and
> a touchpad-description file? Possibly because nobody thinks that is a good
> idea?
>
> I am pretty certain that it would be possible to move the shared part
> (basically what libxkbcommon does) into libinput, so everybody gets
> keysyms. It would always produce events even if there is a failure to
> translate, and the keycode would be in the event, so no information is ever
> lost, and clients could OPTIONALLY decode the stuff themselves.
>
> The current scheme I think is going to have horrendous annoying bugs when
> the clients, compositor, and input method get out of sync and disagree
> about how the keyboard works and what shift state it is in. It also makes
> it pretty impossible to make a remote wayland to another system using a
> keyboard that is not installed on the local machine.
>
> On 07/25/2014 06:06 AM, Pekka Paalanen wrote:
>
>> On Wed, 23 Jul 2014 09:46:16 +0700
>> Trung Ngo <ndtrung4419 at gmail.com> wrote:
>>
>>  Hi guys,
>>>
>>> In the text protocol, there is a `keysym` event (and a corresponding
>>> `keysym` request in the input-method protocol). In the spec, it is used
>>> to 'notify when a key event was sent.' If I understand correctly then
>>> the whole point of this request/event pair is to fake a key press from
>>> the input method. If so, shouldn't it make more sense to intercept the
>>> keysym request at the compositor and send a key press event to the text
>>> application instead of passing the keysym event to the text application
>>> (no more keysym event in the text protocol)?
>>>
>>> In the current design, the text application has to listen to the keysym
>>> event (for fake keys) and implement the key handler (for 'normal' keys)
>>> at the same time, potentially duplicating code and opening up the
>>> posibility that some applications forget to implement the keysym event
>>> handler.
>>>
>>
>> I'm no expert on input, but that is all deliberate.
>>
>> "Normal keys" are direct user actions, a person pressing a key on a
>> keyboard. These originate from a real physical action, specifically a
>> key press/release. These use key codes, which in the clients are
>> interpreted through libxkbcommon to take account the keymap and
>> whatnot. If a keymap does not provide some keysym, you cannot input it,
>> AFAIU.
>>
>> Input methods however use whatever (even complicated) UI that lets the
>> user to choose which symbol to enter. For instance, it can be a virtual
>> keyboard with all kinds of exotic symbols, poked with a finger. There
>> are no physical keys to press. Or it could be just the "compose key"
>> mechanism. Or a machine vision system interpreting sign language.
>>
>> These are fundamentally very different kinds of input. We have a strict
>> separation in the protocol design between actual physical user actions
>> (e.g. poking a button) and "fake" events, and we intend to keep these
>> two separated all the way. For example, wl_pointer.motion is sent only
>> when the user moves the pointer, not when e.g. the window moves under
>> the pointer or the pointer gets warped programmatically.
>>
>> The burden of implementation is in toolkits, not applications.
>>
>>
>> Thanks,
>> pq
>> _______________________________________________
>> wayland-devel mailing list
>> wayland-devel at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
>>
>>  _______________________________________________
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20140725/1c72fab6/attachment-0001.html>