Compositor grabs (was: Re: [PATCH] protocol: Add DnD actions)

[Carlos Garnacho]

Hey Michal,

On Fri, Apr 17, 2015 at 2:47 PM, Michal Suchanek <hramrach at gmail.com> wrote:
<snip>

>> In the X11 world, this would roughly be a Virtual Core
>> Pointer+Keyboard grab (not that touch and active grabs are trouble
>> free in X11, but...), GTK+ for example does grab both devices on every
>> of those grabbing places wayland/xdg protocols are trying to cater for
>> (I've even pondered about adding a gdk_device_grab_pair() for years).
>>
>> I think some consistent model should be devised here, and embedded
>> into the protocol (docs).
>>
>
> The serious problem with X11 grabs is that they are completely
> independent of the event that triggered them and can only be released
> by the application that started them.
>
> So it happens that an application that gets stuck due to code error or
> is running in a debugger at the time a grab is active never releases
> the grab which
>
> 1) prevents other applications from receiving input
> 2) prevents further grabs
>
> It might be worth considering if there is generic enough drag semantic
> that the grab could be handled in compositor outside of application
> code, even with click-lock and whatnot.

Nothing prevents wayland compositors today from undoing grabs when
clients get destroyed, or surfaces don't respond to pings. Affecting
this proposal, the pointer should re-enter the surface underneath and
keyboard focus restablished after the grab is "broken".

>
> During a grab you might want to
>
> 1) process seemingly unrelated events in the grabbing application (eg.
> Esc for canceling the action in the application)

This IMO belongs in the context of the grab, xdg_popup grabs are just
"grab on this surface", this comes off naturally if "focus it in" is
implied. As for DnD grabs, the compositor essentially replaces
wl_pointer/keyboard/touch semantics with wl_data_device ones, I
believe whatever happens must happen on the current semantics, not as
result of a mixture.

> 2) process 'global' window management keybindings (eg. close any
> random application, including the one that is grabbing input)
> 3) perform window management action (eg. raise the intended drag
> target with mouse movement if you have bindings for raising widows
> with mouse movement)
>  - note that you might want to be able to raise windows with DnD
> active but not with a slider active
>
> As to what happens with unrelated input that is not consumed by
> compositor is questionable. Canceling all but the input that started
> the grab might seem like a good idea but what if I am manipulating a
> window with two fingers and then I get the idea to slide a slider with
> third finger?

That'd be an "implicit" grab, I was mainly talking about "active"
compositor grabs (using X11isms here). Implicit grabs shouldn't ever
affect each other.

>
> IMHO the two finger gesture should continue at the very least after I
> release the slider but preferably even as I manipulate the slider.

What I'd expect to happen (and mutter/gtk+ certainly do/allow that) is:
- both things may happen simultaneously
- if those two operations are mutually exclusive, it is the client
responsibility to make them so.

Note I'm talking exclusively about implicit grabs here. The toolkit
should automatically cater for the cases where input is being taken
away, be it compositor or toolkit-internal grabs.

Cheers,
  Carlos