Compositor grabs (was: Re: [PATCH] protocol: Add DnD actions)
carlosg at gnome.org
Mon Apr 20 04:05:23 PDT 2015
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
> 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
- 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
> go to the grab client.
> Wayland could guarantee that the release and drag events go to the
> 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
> two different widgets and get two grabs. Instead one of them will
> 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?
More information about the wayland-devel