diff options
| author | Henrik Rydberg <rydberg@euromail.se> | 2010-08-06 21:11:17 +0200 |
|---|---|---|
| committer | Henrik Rydberg <rydberg@euromail.se> | 2010-08-06 21:11:17 +0200 |
| commit | 7db9d8d76ff61c4802ac15559dcea6fa54ff567a (patch) | |
| tree | b67e040c0abeb0ab1fca72754a767dc9ab851461 /docs/grail-problems.txt | |
initial bzr repo at rev 27
Diffstat (limited to 'docs/grail-problems.txt')
| -rw-r--r-- | docs/grail-problems.txt | 60 |
1 files changed, 60 insertions, 0 deletions
diff --git a/docs/grail-problems.txt b/docs/grail-problems.txt new file mode 100644 index 0000000..0713288 --- /dev/null +++ b/docs/grail-problems.txt | |||
| @@ -0,0 +1,60 @@ | |||
| 1 | Split gestures into recognition and application | ||
| 2 | ----------------------------------------------- | ||
| 3 | |||
| 4 | Gesture detection is not an exact science, but the algorithms | ||
| 5 | inevitably involve decisions influenced by what gestures are available | ||
| 6 | to choose from. Therefore, the recognition should be considered an | ||
| 7 | inherent property of the device itself, regardless of user interaction | ||
| 8 | context. Just imagine having a keyboard that resized slightly | ||
| 9 | everytime you switched from chrome to gimp. | ||
| 10 | |||
| 11 | |||
| 12 | Tag events as being part of a gesture | ||
| 13 | ------------------------------------- | ||
| 14 | |||
| 15 | One of the problems faced when replacing one set of events with | ||
| 16 | another is where and how this filtering should take place. One window | ||
| 17 | might listen for spiral gestures, whereas another window is a paint | ||
| 18 | program where you actually want to draw a spiral. By introducing a | ||
| 19 | relation between a gesture and an event, filtering becomes something | ||
| 20 | simple that can be performed close to the window. The relation can be | ||
| 21 | implemented as a bitmask representing what gestures the event is part | ||
| 22 | of. | ||
| 23 | |||
| 24 | |||
| 25 | Help the client to keep track of active gestures | ||
| 26 | ------------------------------------------------ | ||
| 27 | |||
| 28 | A gesture starts, continues, and either completes or aborts. | ||
| 29 | A client that listens to a subset of gestures will have to keep track. | ||
| 30 | Compatible to Qt approach. | ||
| 31 | |||
| 32 | |||
| 33 | Allow clients to listen to different gestures | ||
| 34 | --------------------------------------------- | ||
| 35 | |||
| 36 | Clients listening on certain gestures will get those gesture events that | ||
| 37 | apply to the client, which makes it possible for different clients to | ||
| 38 | listen to different types of gestures. For instance, having an MT drawing | ||
| 39 | program next to a web browser, a two finger stroke in the drawing program | ||
| 40 | will result in two lines, whereas in the web browser, it will scroll the | ||
| 41 | text. | ||
| 42 | |||
| 43 | |||
| 44 | Propagate gesture events based on the focus point | ||
| 45 | ------------------------------------------------- | ||
| 46 | |||
| 47 | Like pointer events, a gesture applies to a window or a window manager, | ||
| 48 | based on where it is performed on the screen. In order to route the gesture | ||
| 49 | events to the right window, we propagate them through the window hierarchy | ||
| 50 | based on the gesture focus points. Based on the target windows, their | ||
| 51 | respective gesture type masks, and the active set of gestures, final | ||
| 52 | gesture events are emitted to the right windows. | ||
| 53 | |||
| 54 | |||
| 55 | Allow Window Manager to grab system-wide gestures | ||
| 56 | ------------------------------------------------- | ||
| 57 | |||
| 58 | Even if clients are not listening to global window-manager gestures, it | ||
| 59 | could well be that no other gestures should be displayed while the global | ||
| 60 | gesture is taking place. | ||
