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

[Wander Lairson Costa]

2013/9/26 Jason Ekstrand <jason at jlekstrand.net>:

[snip]

>> > 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?
>
>
> This question comes up all the time.  The simple answer here is that the
> negotiation protocol hasn't been written yet.  Why hasn't it been written?
> Primarily because it hasn't become an issue yet.  The only people really
> pushing for server-side are the KWin people.  However, they are still
> working on porting to Qt 5 and QtQuick 2.  Once they get to implementing the
> Wayland bits and *if* they still want to do server-side decorations at that
> point, one of them will probably start working on such a protocol.
>
>>
>> > 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.
>
>
> For now, just draw decorations when not fullscreen.  Once a negotiation
> protocol gets developed, you can implement it.
>

Ok.

>>
>>
>> > 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.
>
>
> Looking at weston's input.c, I am not seeing any evidence that it sends any
> key events due to an enter.  It does resend the modifiers, but that's
> different.  It doesn't make sense to me that you would send the currently
> depressed keys as an array and then send them again one-at-a-time.
>

I did a quick test, and indeed keys are not resent. However, I could
not test modifiers because when I hold a modifier, I couldn't switch
windows.

I just arrived from an work trip and haven't time to check weston code yet.

>>
>> >
>> >>
>> >> > 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.
>
>
> In theory, a client should not be able to notice that more than one keyboard
> is plugged into a seat.  I'm not sure that that is correctly implemented in
> weston right now, but I seem to remember it being the case.  A better person
> to ask about that would be Daniel Stone.
>
> Thanks,
> --Jason Ekstrand



-- 
Best Regards,
Wander Lairson Costa