On Fri, 2010-10-08 at 13:37 +0200, Henrik Rydberg wrote:
On 10/05/2010 10:22 PM, Chase Douglas wrote:
[...]
The reason this is useful is to lower the latency when there's
system-wide and application specific gesture recognition to be
performed. It requires a trust of the client applications to not handle
the events as though they owned them, but X trusts client applications
with lots of similar things today without issue.
It seems to me that the idea of tentative events is not so much about latency as
it is about implementing user feedback which helps resolve ambiguities.
It's the latency to the user feedback that's important. In my mind,
these two concepts are one in the same.
There are at least three stages in gesture recognition in this respect. In the
first stage, the engine builds up a reaction based on user input, from nothing
to something. I see no reason to send this buildup anywhere at all. In the
second stage, something is happening, and the user may need feedback from the
system to tell that something has been registered. This is equivalent to our
notion of gesture primitives, and could well be represented by tentative events,
although I see no compelling reason to change views. The third stage is to
perform a user-approved gesture, which is on a higher level than what we have
implemented so far, and could be a good target for geis.
The sticky point comes when we need to handle the possibility for both
gestures and low-latency multitouch input. For example, think of the
three finger hold to unlock many finger MT and gestures occurring over a
paint application. With the proposed XI 2.1 passive grabbing paradigm,
gimp will receive tentative events and may start painting, knowing that
it will need to undo those paints if the events should be discarded.
This should occur as immediately as possible after touches hit the
screen.
