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

[Michal Suchanek]

On 17 April 2015 at 16:15, Carlos Garnacho <carlosg at gnome.org> wrote:
> 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".

Nothing prevents the X server either. It hopefully breaks the grabs
initiated by clients when they are destroyed, too. However, there is
no mechanism for breaking a grab of a client other than destroying it
*and* destroying the client cannot be done from within the X session
because it is grabbed.

Thanks

Michal