Compositor grabs (was: Re: [PATCH] protocol: Add DnD actions)
spitzak at gmail.com
Mon Apr 20 12:01:53 PDT 2015
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.
More information about the wayland-devel