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

[Bill Spitzak]

On 04/20/2015 04:05 AM, Carlos Garnacho wrote:

> - The last touch drags the window, the previous ones remain static and
> are eventually lifted. Why do they apply where your finger no longer
> is? Why do they apply at all? can one of these touches create an
> xdg_popup (and another grab on another touch) while window dragging is
> going on?

It should send touch-moved events to the first client. So if they hold 
down their fingers on the painting program and then use the mouse to 
move the window, they will cause paintstrokes to be made.

Note as Wayland is currently designed the client is in control of 
whether any event moves it's window, so it will know if this is 
happening, and is free to either cancel the touch handling or not drag 
the window, if it does not like this.

> - You're about to start some critical/expensive operation and the
> screensaver kicks in before you lift the finger, because of low
> battery. Should you be allowed to blindly get the operation started
> while the system is preparing to halt/suspend?

Your actual question applies just as well to an expensive operation that 
was launched before the screensaver started, but is still running. Maybe 
there is a "battery is low and we are stopping" event that the client 
can use to stop or prevent the expensive operation. I think this event 
could be sent whether or not a grab is happening.

The screensaver should be blocked by server-started grabs (ie due to 
buttons being held down). Client-started grabs probably will survive and 
continue after the screensaver is unlocked.

> I see this model falling apart really soon. I suggest we first
> identify if there's usecases we're actually fixing here before we go
> original about grabs/capturing as the user interaction paradigm.
>
> Grabs are basically a contract, in which you get a guarantee that:
> a) You get all input from that device
> b) You are the only receiver of such input
>
> Touch events are highly transient (eg. there's not even guarantee that
> the touch starting the grab is the one that finishes it), as such it
> doesn't make sense to grab on sequences individually, but on the whole
> capability. This "we grab all future touches, we don't grab the past
> ones though, except the triggering one" policy seems highly
> inconsistent to me.

I certainly intended that all touches on the same device go to the same 
grab. Since the triggering one will be sent to the same client as the 
past ones which already caused a grab, your concern does not happen.

The problem is if there are multiple seats.

It is also possible that there are multiple grabs per seat, perhaps 
divided up by device, or perhaps sets of devices or devices split 
between grabs. I am unsure if this is necessary, I feel like there could 
be exactly one grab per seat and everything, including keystrokes, goes 
to the grab client.