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

[Carlos Garnacho]

On vie, 2015-04-17 at 14:40 -0700, Bill Spitzak wrote:
> On 04/17/2015 05:16 AM, Carlos Garnacho wrote:
> 
> > 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?
> 
> The touches held down should continue to go to the surface they were 
> going to before, while the events related to the event that 
> triggered 
> the grab will go to the grab client.

I very much disagree. Let's see the following scenarios:

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

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

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.

> 
> When the two touches are fully released then the next press of them 
> will 
> go to the grab client.
> 
> Wayland could guarantee that the release and drag events go to the 
> same 
> client that got the press event. Grabs just dictate where new press 
> events go.
> 
> I don't think this situation will happen much, due to server-induced 
> grabs which are fully synchronous, so you cannot press two buttons 
> in 
> two different widgets and get two grabs. Instead one of them will 
> get 
> the grab and that one will see the other button.

There's legit places where you want to overwrite/stack a grab within 
the compositor, say when the screensaver kicks in while a xdg_popup is 
present. The same concerns with your model arise in this case of 
grabbed devices being transferred from one grab to another, is the 
previous grab held partly in control?

Cheers,
  Carlos