Some of my thoughts on input for wayland
spitzak at gmail.com
Mon Jan 24 20:07:35 PST 2011
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.
More information about the wayland-devel