[xkbcommon] How to distinguish left-shift and right-shift

[Wander Lairson Costa]

2013/9/26 Ran Benita <ran234 at gmail.com>:
> On Thu, Sep 26, 2013 at 06:27:39PM -0300, Wander Lairson Costa wrote:
>> 2013/9/26 Ran Benita <ran234 at gmail.com>:
>> > On Thu, Sep 26, 2013 at 04:00:15PM -0300, Wander Lairson Costa wrote:
>> >> 2013/9/26 Ran Benita <ran234 at gmail.com>:
>> >>
>> >> [snip]
>> >>
>> >> >
>> >> > The information you need, if you want to use the key-down approach
>> >> > (which is the only one I can think of), is whether e.g. the Left Shift
>> >> > key is down at any given moment. This keys-state information is kept on
>> >> > the compositor, but now you need to reconstruct it on the client. The
>> >> > way to do it is as I outlined above, i.e. wl_keyboard.enter event, which
>> >> > gives you a wl_array of all the keys which are pressed +
>> >> > wl_keyboard.key events, which allow you to keep this array in sync.
>> >> >
>> >>
>> >> This is what I was thinking about.
>> >>
>> >> > (Though by a quick look at the Weston code, it might be that it sends
>> >> > key-down events for all the keys which are down when the focus is
>> >> > changed, that is, it replays what happened to get to the current state.
>> >> > So maybe you don't need the information in the wl_keyboard.enter after
>> >> > all, only the key events with an initial empty array. It should be easy
>> >> > to check which way is it).
>> >> >
>> >>
>> >> But this is an weston implementation detail, I guess, other
>> >> compositors may not have the same behavior.
>> >
>> > Good point, I can't find it specified either. I think whatever the
>> > current behavior is, it should be specified in wayland.xml, so people can
>> > rely on it. In some cases, such "undefined behavior" can be a real
>> > hinderance, for example if you want to keep a 'press-count' for a key
>> > (there can be cases like two keyboards in the same seat, so *two* Left
>> > Shift keys can be down at the same time, etc). And since Wayland will
>> > have many compositors, you don't have a de facto standard like X server,
>> > and they *will* do it differently, I expect...
>> >
>>
>> This kind of "undefined behavior" does not happen only on this case.
>>
>> For example, I have been wondering about window decoration. AFAIK,
>> Wayland leaves to the compositor thr decision if window decoration should be
>> client side or server side. In weston, it is client side, KWin will be
>> server side, how an application would know if it has to decorate its
>> own window or not?
>> (This is a more general question that may deserve its own thread)
>
> I'm not a Wayland developer, so I can't say with confidence. But I think
> this choice is deferred to the toolkit layer. In this case both
> behaviors (server of client side decorations) are potentially useful, so
> the protocol shouldn't *require* one or the other.

I fail to see success on this approach. Today you can run kde
applications under gnome
(and vice versa). What about if, with wayland, KDE does server side
decoration and gnome chooses
client side decoration, what would a kde application running under
gnome look like?

> Though I guess for the
> issue you mentioned, maybe there should be some protocol to tell the
> client whether it should draw decorations or not.
>

Yes, because Blender does not use any toolkit.


> But this is not the case for the key-replay behavior. There's nothing to
> be gained by letting different compositors do different things in this
> case. Both behaviors are fine IMO, so should just require whatever
> Weston does currently.

I hope compositors agree on following the same path for "undefined behaviors",
otherwise toolkits and applications will have a hard time to come.

>
>>
>> > So if you see what happens exactly, it'd be nice if you open a bug, or
>> > post back, or send a patch :)
>>
>> Do you mean about the behavior when we have more than one keyboard
>> attached to a seat?
>
> No, that should work seamlessly. I meant the replay of the key press
> events (after you manage to implement your stuff in a real world
> application like Blender).
>

Not a problem, I will do that.


-- 
Best Regards,
Wander Lairson Costa