Kristian Høgsberg wrote:
On Mon, Jan 24, 2011 at 4:04 PM, Bill Spitzak <[email protected]> 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.
_______________________________________________
wayland-devel mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
