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

[Peter Hutterer]

sorry, quite late to the discussion here

On Fri, Apr 17, 2015 at 04:27:19PM +0200, Michal Suchanek wrote:
> 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.

that's not quite true. the protocol specifies the behaviour of a grab in
detail and there is no server-initiated escape from an activated grab,
active or passive. you could cancel the grab de-facto (i.e. make the device
interact with other client again) but you'd then have to maintain a fake
grab state for the grabbing client until it releases. and since you can't
know what the trigger for the release is (movement? button?), you're pretty
much stuck.

forcibly killing the grab is possible, but then you have to assume the
client will crash in one way or another.

Cheers,
   Peter