Finished 'Design' chapter.

docs/report.tex

@@ -467,14 +467,15 @@ goal is to test the effectiveness of the design and detect its shortcomings.
 
     The design of the architecture is essentially complete with the components
     specified in this chapter. However, one specification has not yet been
-    discussed: the ability address the architecture using a method of
-    communication independent of the application programming language.
+    discussed: the ability to address the architecture using a method of
+    communication independent of the application's programming language.
 
-    If an application must start the architecture instance in a thread within
-    the application itself, the architecture is required to be compatible with
-    the programming language used to write the application. To overcome the
-    language barrier, an instance of the architecture would have to run in a
-    separate process.
+    If the architecture and a gesture-based application are written in the same
+    language, the main loop of the architecture can run in a separate thread of
+    the application. If the application is written in a different language, the
+    architecture has to run in a separate process. Since the application needs
+    to respond to gestures that are triggered by the architecture, there must
+    be a communication layer between the separate processes.
 
     A common and efficient way of communication between two separate processes
     is through the use of a network protocol. In this particular case, the
@@ -485,7 +486,7 @@ goal is to test the effectiveness of the design and detect its shortcomings.
     \vspace{-0.3em}
     \daemondiagram
 
-    An advantage of a daemon setup is that is can serve multiple applications
+    An advantage of a daemon setup is that it can serve multiple applications
     at the same time. Alternatively, each application that uses gesture
     interaction would start its own instance of the architecture in a separate
     process, which would be less efficient.
@@ -503,16 +504,16 @@ goal is to test the effectiveness of the design and detect its shortcomings.
 \begin{verbatim}
 initialize GUI framework, creating a window and nessecary GUI widgets
 
-create a root area that synchronizes position and size with the application window
-define 'rotation' gesture handler and bind it to the root area
+create a root event area that synchronizes position and size with the application window
+define 'rotation' gesture handler and bind it to the root event area
 
-create an area with the position and radius of the circle
-define 'drag' gesture handler and bind it to the circle area
+create an event area with the position and radius of the circle
+define 'drag' gesture handler and bind it to the circle event area
 
-create an area with the position and size of the button
-define 'tap' gesture handler and bind it to the button area
+create an event area with the position and size of the button
+define 'tap' gesture handler and bind it to the button event area
 
-create a new event server and assign the created root area to it
+create a new event server and assign the created root event area to it
 
 start the event server in a new thread
 start the GUI main loop in the current thread
@@ -525,8 +526,8 @@ start the GUI main loop in the current thread
 A reference implementation of the design has been written in Python. Two test
 applications have been created to test if the design ``works'' in a practical
 application, and to detect its flaws. One application is mainly used to test
-the gesture tracker implementations. The other program uses areas in a tree,
-demonstrating event delegation and propagation.
+the gesture tracker implementations. The other program uses multiple event
+areas in a tree structure, demonstrating event delegation and propagation.
 
 To test multi-touch interaction properly, a multi-touch device is required. The
 University of Amsterdam (UvA) has provided access to a multi-touch table from
@@ -556,7 +557,7 @@ The reference implementation is written in Python and available at
     \item Transformation tracker, supports $rotate,~pinch,~drag$ gestures.
 \end{itemize}
 
-\textbf{Areas}
+\textbf{Event areas}
 \begin{itemize}
     \item Circular area
     \item Rectangular area
@@ -567,10 +568,10 @@ The implementation does not include a network protocol to support the daemon
 setup as described in section \ref{sec:daemon}. Therefore, it is only usable in
 Python programs. Thus, the two test programs are also written in Python.
 
-The area implementations contain some geometric functions to determine whether
-an event should be delegated to an area. All gesture trackers have been
-implemented using an imperative programming style. Technical details about the
-implementation of gesture detection are described in appendix
+The event area implementations contain some geometric functions to determine
+whether an event should be delegated to an event area. All gesture trackers
+have been implemented using an imperative programming style. Technical details
+about the implementation of gesture detection are described in appendix
 \ref{app:implementation-details}.
 
 \section{Full screen Pygame program}
@@ -602,11 +603,11 @@ The application receives TUIO events and translates them to \emph{point\_down},
 interpreted to be \emph{single tap}, \emph{double tap}, \emph{rotation} or
 \emph{pinch} gestures. The positions of all touch objects are drawn using the
 Pygame library. Since the Pygame library does not provide support to find the
-location of the display window, the root area captures events in the entire
-screens surface. The application can be run either full screen or in windowed
-mode. If windowed, screen-wide gesture coordinates are mapped to the size of
-the Pyame window. In other words, the Pygame window always represents the
-entire touch surface. The output of the program can be seen in figure
+location of the display window, the root event area captures events in the
+entire screens surface. The application can be run either full screen or in
+windowed mode. If windowed, screen-wide gesture coordinates are mapped to the
+size of the Pyame window. In other words, the Pygame window always represents
+the entire touch surface. The output of the program can be seen in figure
 \ref{fig:draw}.
 
 \begin{figure}[h!]
@@ -625,7 +626,7 @@ The second test application uses the GIMP toolkit (GTK+) \cite{GTK} to create
 its user interface. Since GTK+ defines a main event loop that is started in
 order to use the interface, the architecture implementation runs in a separate
 thread. The application creates a main window, whose size and position are
-synchronized with the root area of the architecture.
+synchronized with the root event area of the architecture.
 
 % TODO
 \emph{TODO: uitbreiden en screenshots erbij (dit programma is nog niet af)}
@@ -656,7 +657,7 @@ synchronized with the root area of the architecture.
 \section{A generic method for grouping events}
 \label{sec:eventfilter}
 
-As mentioned in section \ref{sec:areas}, the concept of an \emph{area} is based
+As mentioned in section \ref{sec:areas}, the concept of an event area is based
 on the assumption that the set or originating events that form a particular
 gesture, can be determined based exclusively on the location of the events.
 Since this thesis focuses on multi-touch surface based devices, and every
@@ -673,12 +674,12 @@ of events that consist of these parameters.
 
 A more generic term for a component that groups similar events is the
 \emph{event filter}. The concept of an event filter is based on the same
-principle as areas, which is the assumption that gestures are formed from a
-subset of all events. However, an event filter takes all parameters of an event
-into account. An application on the camera-based multi-touch table could be to
-group all objects that are triangular into one filter, and all rectangular
-objects into another. Or, to separate small finger tips from large ones to be
-able to recognize whether a child or an adult touches the table.
+principle as event areas, which is the assumption that gestures are formed from
+a subset of all events. However, an event filter takes all parameters of an
+event into account. An application on the camera-based multi-touch table could
+be to group all objects that are triangular into one filter, and all
+rectangular objects into another. Or, to separate small finger tips from large
+ones to be able to recognize whether a child or an adult touches the table.
 
 \section{Using a state machine for gesture detection}