From 7db9d8d76ff61c4802ac15559dcea6fa54ff567a Mon Sep 17 00:00:00 2001 From: Henrik Rydberg Date: Fri, 6 Aug 2010 21:11:17 +0200 Subject: initial bzr repo at rev 27 --- docs/grail-problems.txt | 60 +++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 60 insertions(+) create mode 100644 docs/grail-problems.txt (limited to 'docs/grail-problems.txt') 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 @@ +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. + + +Allow clients to listen to different gestures +--------------------------------------------- + +Clients listening on certain gestures will get those gesture events that +apply to the client, which makes it possible for different clients to +listen to different types of gestures. For instance, having an MT drawing +program next to a web browser, a two finger stroke in the drawing program +will result in two lines, whereas in the web browser, it will scroll the +text. + + +Propagate gesture events based on the focus point +------------------------------------------------- + +Like pointer events, a gesture applies to a window or a window manager, +based on where it is performed on the screen. In order to route the gesture +events to the right window, we propagate them through the window hierarchy +based on the gesture focus points. Based on the target windows, their +respective gesture type masks, and the active set of gestures, final +gesture events are emitted to the right windows. + + +Allow Window Manager to grab system-wide gestures +------------------------------------------------- + +Even if clients are not listening to global window-manager gestures, it +could well be that no other gestures should be displayed while the global +gesture is taking place. -- cgit v1.2.3