Some of my thoughts on input for wayland

[Bill Spitzak]

Kristian Høgsberg wrote:
> On Mon, Jan 24, 2011 at 4:04 PM, Bill Spitzak <spitzak at gmail.com> wrote:
>> Chase Douglas wrote:
>>
>>> Heh, I've heard his distaste of grabs. I haven't had a chance to
>>> research other mechanisms, so I'm just going on what I know through X.
>>> I'm certainly not opposed to a better mechanism :).
>> I really believe passive grabs can be replaced by adding an API that says "I
>> did not handle this event". It can then be passed to another window. The
>> typical grabber would be the *last* one in line, not the first. Wayland
>> itself would have simple unchangable rules about what windows receive
>> events, but these rules produce a list and it tries each in turn.
> 
> Wayland isn't going to support passive grabs.  They're essentially
> only used for global keybindings and some window manager behaviour
> such as Alt-Click to move a window.  Since the window manager is the
> display server, the window manager can just look for the input
> combinations that would trigger a grab in the X model and handle them
> internally.  Applications will want to install keybindings (like a
> media player that wants to handle the media keys) but that's already
> handled by the window manager or a desktop daemon.  Applications
> install a config file in a keybindings.d type directory read by the
> window manager or install into a well defined gconf directory or
> something along those lines.

That's a good point. There is no need for passive grabs because the 
compositor, in effect, has a passive grab on *everything*.

I still think it would be useful for there to be an API so that an 
application can say "I did not use that event". The compositor could use 
this so that ignored clicks and keystrokes can do some other action.

I'm not sure if I have any great examples however. The one I was 
thinking of was having clicks raise and move windows only if they are in 
an "inactive" area. But raise and move should be done by the client 
anyway, so that is pointless. The media keys though may be an example. 
An application can use them directly but if they ignore them they have 
the normal effect. If the user hits volume-up it would move the current 
app's volume control up, but when it hits the top it is ignored and the 
main volume control goes up instead.

I'm wary of a "config" file the window manager reads. What users want to 
do is go into the application and run some control panel that says "now 
the shortcut X+Y+Z does this" and it starts happening, and they can then 
change their mind and it goes back to the way it was before. Having to 
write a file to do this and signal the compositor that it changed does 
not sound like a very nice design.