[RFC] Global binding

[Bill Spitzak]

Quentin Glidic wrote:

> I use a mouse button as my Push-to-Talk button. This button is
> detected as “History back” by my web browser, and *I want to have both
> working.*

I think you are confusing what I was complaining about (which was the 
idea that there is some difference between your bind "actions" and the 
events sent from the compositor to clients. Basically if the compositor 
is going to do a lot of decoding, then decoded result should be sent to 
the clients in events).

For your request, I think whether a binding "eats" the event can be a 
fixed setting for each gesture. Ie mouse buttons and modifier keys are 
not eaten, all keys that produce text are eaten, etc.

> Also, binding gestures and complex stuff is a really good feature to
> have (think of three-thingers scrolling to up/down volume as an
> example), and more easily done on the compositor side since that would
> require to expose yet another information (pointer movement, touchscreen
> touches) to the client.

I agree that translating "gestures" should be done by the compositor.

But I would like to see the simplest gestures attacked first: the 
"gesture" of pushing a button with the text "FOOBAR" on it should send 
an event containing the text "FOOBAR" to the client!

Or just maybe all the gestures should be done by the client. That would 
be consistent at least. I would prefer that the compositor does it all 
however.

>> Events should certainly be decoded to more like the xkeysym level
> 
> AFAIU, the decoding is done by libxkbcommon and it was designed so that
> clients would have to support that explicitly. This has nothing to do
> with global bindings.

I think that is a serious mistake. The biggest problem I have with 
remote X (both NX and normal $DISPLAY) is bungled scancodes because the 
local x server has to backwards translate key events into phony 
scancodes. When I log in remotely I always have to run xmodmap with a 
special table to fix this. This is obviously a buggy hack and Wayland 
should fix it.

> Please note that music and video players are not currently using
> multimedia keys directly: mplayer and VLC are using the space bar as
> play/pause (while focused, of course), VLC uses the mouse wheel to
> control volume. This is a good design, to keep the global keys usable at
> the system level (e.g. controlling the PCM volume).

I want the multimedia app to be able to decide whether the volume 
up/down adjust it's volume or the global one. What I proposed was that 
all events go to the clients and they can say they did not handle them 
(thus the volume buttons go to the focused media player, but adjust the 
global volume if the focues app ignores them). I think there is dislike 
for this idea, so I now propose that it be moved to the binding api.

> That would require a round trip and that would be wrong is some (many?)
> cases: I have two music players A and B, I focused B last, why would A
> have to decline the action if it can handle that perfectly, since it
> does not have the knowledge that B exists at all?

It would be sent to B first (as you proposed, they are sent to the 
last-focused client). The only change I was making is that B could say 
"I did not use it" and then (perhaps) A gets it.