Commit e38f4592 authored by Taddeüs Kroes's avatar Taddeüs Kroes

Started 'Reference implementation' section and added a diagram about the daemon setup.

parent fd0dce6f
% Define node group background % Define node group background
% The first 4 arguments are nodes that define the group borders in (left, % The first 4 arguments are nodes that define the group borders in (left,
% top, right, bottom) order, the last argument is a text label % top, right, bottom) order, the last argument is a text label
\usetikzlibrary{shapes,arrows} \usetikzlibrary{shapes,arrows,positioning}
\pgfdeclarelayer{background} \pgfdeclarelayer{background}
\pgfdeclarelayer{foreground} \pgfdeclarelayer{foreground}
\pgfsetlayers{background,main,foreground} % Layer order \pgfsetlayers{background,main,foreground} % Layer order
...@@ -244,21 +244,6 @@ ...@@ -244,21 +244,6 @@
\end{figure} \end{figure}
} }
\newcommand{\examplefigurethree}{
\begin{figure}[h]
\center
\begin{tikzpicture}
\draw node[draw=black, minimum width=190, minimum height=140] (screen) at (0,0) {};
\draw node[fill=gray!50, draw=black!70, minimum height=100, minimum width=100] (screen) at (-0.1,-0.1) {};
\draw node[fill=white, draw=black!80, diamond, minimum height=50, minimum width=50] (screen) at (0.3,0.4) {};
\end{tikzpicture}
\caption{Two overlapping squares that listen to rotation. When the
white square is rotated, the gray square should keep its current
orientation and vice-versa.}
\label{fig:ex3}
\end{figure}
}
\newcommand{\eventpropagationfigure}{ \newcommand{\eventpropagationfigure}{
\begin{figure}[h!] \begin{figure}[h!]
\center \center
...@@ -321,3 +306,31 @@ ...@@ -321,3 +306,31 @@
\label{fig:eventpropagation} \label{fig:eventpropagation}
\end{figure} \end{figure}
} }
\newcommand{\daemondiagram}{
\begin{figure}[h!]
\center
\begin{tikzpicture}[node distance=4em]
\node[block] (daemon) {Daemon};
\node[block, above of=daemon] (driver) {Device driver}
edge[lineto] (daemon);
\node[block, xshift=-4em, left of=driver] {Device driver}
edge[lineto] (daemon);
\node[block, xshift=4em, right of=driver] {Device driver}
edge[lineto] (daemon);
\node[block, below of=daemon] (app) {Application}
edge[linefrom, dotted] (daemon);
\node[block, xshift=-4em, left of=app] {Application}
edge[linefrom, dotted] (daemon);
\node[block, xshift=4em, right of=app] {Application}
edge[linefrom, dotted] (daemon);
\draw[dashed] (app.north)+(-4, 0.35) -- node[right=4, yshift=1] {Network protocol} ++(4, 0.35);
\end{tikzpicture}
\caption{Daemon setup of an architecture implementation, serving
gestures to multiple applications at the same time.}
\label{fig:ex3}
\end{figure}
}
...@@ -157,3 +157,10 @@ ...@@ -157,3 +157,10 @@
year = 1997 year = 1997
} }
@misc{gitrepos,
author = "Kroes, Tadde{\"u}s",
howpublished = "\url{http://git.kompiler.org/uva-multitouch/}",
title = "{Git repository of reference implementation}",
year = "2012"
}
...@@ -162,10 +162,10 @@ goal is to test the effectiveness of the design and detect its shortcomings. ...@@ -162,10 +162,10 @@ goal is to test the effectiveness of the design and detect its shortcomings.
This chapter describes the realization of a design for the generic This chapter describes the realization of a design for the generic
multi-touch gesture detection architecture. The chapter represents the multi-touch gesture detection architecture. The chapter represents the
architecture as a diagram of relations between different components. architecture as a diagram of relations between different components.
Sections \ref{sec:driver-support} to \ref{sec:multiple-applications} define Sections \ref{sec:driver-support} to \ref{sec:daemon} define requirements
requirements for the architecture, and extend the diagram with components for the architecture, and extend the diagram with components that meet
that meet these requirements. Section \ref{sec:example} describes an these requirements. Section \ref{sec:example} describes an example usage of
example usage of the architecture in an application. the architecture in an application.
The input of the architecture comes from a multi-touch device driver. The input of the architecture comes from a multi-touch device driver.
The task of the architecture is to translate this input to multi-touch The task of the architecture is to translate this input to multi-touch
...@@ -441,7 +441,7 @@ goal is to test the effectiveness of the design and detect its shortcomings. ...@@ -441,7 +441,7 @@ goal is to test the effectiveness of the design and detect its shortcomings.
event propagation, applied to the example of the white and gray squares. event propagation, applied to the example of the white and gray squares.
\section{Serving multiple applications} \section{Serving multiple applications}
\label{sec:multiple-applications} \label{sec:daemon}
The design of the architecture is essentially complete with the components The design of the architecture is essentially complete with the components
specified in this chapter. However, one specification has not yet been specified in this chapter. However, one specification has not yet been
...@@ -460,6 +460,9 @@ goal is to test the effectiveness of the design and detect its shortcomings. ...@@ -460,6 +460,9 @@ goal is to test the effectiveness of the design and detect its shortcomings.
indicate that a process runs as a background process.} process, listening indicate that a process runs as a background process.} process, listening
to driver messages and triggering gestures in registered applications. to driver messages and triggering gestures in registered applications.
\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 is can serve multiple applications
at the same time. Alternatively, each application that uses gesture at the same time. Alternatively, each application that uses gesture
interaction would start its own instance of the architecture in a separate interaction would start its own instance of the architecture in a separate
...@@ -497,46 +500,86 @@ start the GUI main loop in the current thread ...@@ -497,46 +500,86 @@ start the GUI main loop in the current thread
\chapter{Test applications} \chapter{Test applications}
% TODO A reference implementation of the design is written in Python. Two test
% alleen window.contains op point down, niet move/up applications have been created to test if the design ``works'' in a practical
% een paar simpele windows en trackers application, and to detect its flaws. One application is mainly used to test
% Geen netwerk protocol the gesture tracker implementations. The other program uses areas in a tree,
demonstrating event delegation and propagation.
To test multi-touch interaction properly, a multi-touch device is required. The 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 University of Amsterdam (UvA) has provided access to a multi-touch table from
PQlabs. The table uses the TUIO protocol \cite{TUIO} to communicate touch PQlabs. The table uses the TUIO protocol \cite{TUIO} to communicate touch
events. See appendix \ref{app:tuio} for details regarding the TUIO protocol. events. See appendix \ref{app:tuio} for details regarding the TUIO protocol.
The reference implementation is a Proof of Concept that translates TUIO
messages to some simple touch gestures (see appendix \ref{app:implementation}
for details).
% omdat we alleen deze tafel hebben kunnen we het concept van de event driver
% alleen met het TUIO protocol testen, en niet vergelijken met andere drivers
% TODO %The reference implementation and its test applications are a Proof of Concept,
% testprogramma's met PyGame/Cairo %meant to show that the architecture design is effective.
%that translates TUIO messages to some common multi-touch gestures.
\section{Reference implementation} \section{Reference implementation}
\label{sec:implementation} \label{sec:implementation}
\section{Fullscreen Pygame program} % TODO
% een paar simpele areas en trackers
% Geen netwerk protocol
The reference implementation is written in Python and available at
\cite{gitrepos}. The following component implementations are included:
\textbf{Event drivers}
\begin{itemize}
\item TUIO driver, using only the support for simple touch points with an
$(x, y)$ position.
\end{itemize}
\textbf{Gesture trackers}
\begin{itemize}
\item Basic tracker, supports $point\_down,~point\_move,~point\_up$ gestures.
\item Tap tracker, supports $tap,~single\_tap,~double\_tap$ gestures.
\item Transformation tracker, supports $rotate,~pinch,~drag$ gestures.
\end{itemize}
\textbf{Areas}
\begin{itemize}
\item Circular area
\item Rectangular area
\item Full screen area
\end{itemize}
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.
\section{Full screen Pygame program}
% TODO
The first test application was initially implemented without application of the
architecture design. This application was a Python port of a
Processing\footnote{} program found on the internet, with some adaptations to
work with the TUIO protocol.
\section{GTK/Cairo program} \section{GTK/Cairo program}
\chapter{Conclusions} % TODO
\chapter{Suggestions for future work} \chapter{Conclusions}
% TODO % TODO
\chapter{Suggestions for future work}
\section{A generic way for grouping events} \section{A generic way for grouping events}
\label{sec:eventfilter} \label{sec:eventfilter}
% TODO
% - "event filter" ipv "area" % - "event filter" ipv "area"
\section{Using a state machine for gesture detection} \section{Using a state machine for gesture detection}
% TODO
% - gebruik formelere definitie van gestures ipv expliciete detection logic, % - gebruik formelere definitie van gestures ipv expliciete detection logic,
% bijv. een state machine % bijv. een state machine
\section{Daemon implementation} \section{Daemon implementation}
% TODO
% - network protocol (ZeroMQ) voor meerdere talen en simultane processen % - network protocol (ZeroMQ) voor meerdere talen en simultane processen
% - volgende stap: maken van een library die meerdere drivers en complexe % - volgende stap: maken van een library die meerdere drivers en complexe
% gestures bevat % gestures bevat
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment