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.
_______________________________________________
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
