summaryrefslogtreecommitdiff
path: root/docs/grail-problems.txt
blob: ab95c28645509bf515f32af8d6f049e6a6277332 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
Split gestures into recognition and application
-----------------------------------------------

Gesture detection is not an exact science, but the algorithms
inevitably involve decisions influenced by what gestures are available
to choose from. Therefore, the recognition should be considered an
inherent property of the device itself, regardless of user interaction
context. Just imagine having a keyboard that resized slightly
everytime you switched from chrome to gimp.


Tag events as being part of a gesture
-------------------------------------

One of the problems faced when replacing one set of events with
another is where and how this filtering should take place. One window
might listen for spiral gestures, whereas another window is a paint
program where you actually want to draw a spiral. By introducing a
relation between a gesture and an event, filtering becomes something
simple that can be performed close to the window. The relation can be
implemented as a bitmask representing what gestures the event is part
of.


Help the client to keep track of active gestures
------------------------------------------------

A gesture starts, continues, and either completes or aborts.
A client that listens to a subset of gestures will have to keep track.
Compatible to Qt approach.

Would there be client feedback on confirmation?