1 files changed, 29 insertions, 1 deletions

diff --git a/docs/grail-problems.txt b/docs/grail-problems.txt
index ab95c28..0713288 100644
--- a/docs/grail-problems.txt
+++ b/docs/grail-problems.txt
@@ -29,4 +29,32 @@ 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?
+
+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.