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

[Michal Suchanek]

On 17 April 2015 at 14:16, Carlos Garnacho <carlosg at gnome.org> wrote:
> Hey Jonas,
>
> This is drifting a bit off the topic of the original thread, better to
> spin this off. I'll reply to the DnD bits in another email.
>
> On Fri, Apr 17, 2015 at 9:50 AM, Jonas Ådahl <jadahl at gmail.com> wrote:
>> On Thu, Apr 16, 2015 at 12:55:31PM +0200, Carlos Garnacho wrote:
>>> Hey Jonas,
>>>
>>> On Thu, Apr 16, 2015 at 10:15 AM, Jonas Ådahl <jadahl at gmail.com> wrote:

>>> More generally, I have the opinion that compositors grabs should
>>> behave all consistently, as in:
>>>
>>> - Ensuring clients reset all input state (we eg. don't cancel ongoing
>>> touches when xdg_popup/dnd/... grabs kick in)
>>
>> What does "client reset all input state" mean? What state can a client
>> reset?
>
> Let's expand on that example, maybe far-streched, but certainly possible:
> - I'm manipulating a client window with 2 fingers on the touchscreen
> (say zooming an image)
> - Any other interaction on the client makes it pop up an xdg_popup
> (say a third touch, a key combo, or the pointer)
> - Q: what happens with the two first touches?
>
> Ideally, these touches should be "cancelled" on the first surface
> (wl_touch.cancelled seems to be per client, not per-surface though),
> and stay non-reactive within the grab, so they wouldn't trigger
> anything unintended (they're implicitly grabbed on another surface
> after all)
>
> Currently, on the weston code, focusing a bit on the all-touch case,
> it actually happens the worst that could happen, the xdg_popup touch
> grab redirects already started touch sequences to the grabbing surface
> right away, and the original surface will be deaf to them of a sudden,
> leading to inconsistent state on both the original and the grabbing
> surface wrt those touch sequences. The DnD touch grab doesn't fare
> much better, it will ignore other touches than the one starting the
> drag, so the pre-grab touches would effectively go nowhere, and AFAICS
> similar issues arise with pointer grabs vs touch.
>
> With keyboards, it happens likewise, if compositors are to possibly
> consume events there, focus should move out of the previous surface.
> IMO, any grabbing model that does not redirect all input, nor ensures
> a coherent state in clients is calling for trouble...
>
> 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.

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)
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?

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

Thanks

Michal