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
% The first 4 arguments are nodes that define the group borders in (left,
% top, right, bottom) order, the last argument is a text label
\usetikzlibrary{shapes,arrows}
\usetikzlibrary{shapes,arrows,positioning}
\pgfdeclarelayer{background}
\pgfdeclarelayer{foreground}
\pgfsetlayers{background,main,foreground} % Layer order
......@@ -244,21 +244,6 @@
\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}{
\begin{figure}[h!]
\center
......@@ -321,3 +306,31 @@
\label{fig:eventpropagation}
\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 @@
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.
This chapter describes the realization of a design for the generic
multi-touch gesture detection architecture. The chapter represents the
architecture as a diagram of relations between different components.
Sections \ref{sec:driver-support} to \ref{sec:multiple-applications} define
requirements for the architecture, and extend the diagram with components
that meet these requirements. Section \ref{sec:example} describes an
example usage of the architecture in an application.
Sections \ref{sec:driver-support} to \ref{sec:daemon} define requirements
for the architecture, and extend the diagram with components that meet
these requirements. Section \ref{sec:example} describes an example usage of
the architecture in an application.
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
......@@ -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.
\section{Serving multiple applications}
\label{sec:multiple-applications}
\label{sec:daemon}
The design of the architecture is essentially complete with the components
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.
indicate that a process runs as a background process.} process, listening
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
at the same time. Alternatively, each application that uses gesture
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
\chapter{Test applications}
% TODO
% alleen window.contains op point down, niet move/up
% een paar simpele windows en trackers
% Geen netwerk protocol
A reference implementation of the design is 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.
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
PQlabs. The table uses the TUIO protocol \cite{TUIO} to communicate touch
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
% testprogramma's met PyGame/Cairo
%The reference implementation and its test applications are a Proof of Concept,
%meant to show that the architecture design is effective.
%that translates TUIO messages to some common multi-touch gestures.
\section{Reference 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}
\chapter{Conclusions}
% TODO
\chapter{Suggestions for future work}
\chapter{Conclusions}
% TODO
\chapter{Suggestions for future work}
\section{A generic way for grouping events}
\label{sec:eventfilter}
% TODO
% - "event filter" ipv "area"
\section{Using a state machine for gesture detection}
% TODO
% - gebruik formelere definitie van gestures ipv expliciete detection logic,
% bijv. een state machine
\section{Daemon implementation}
% TODO
% - network protocol (ZeroMQ) voor meerdere talen en simultane processen
% - volgende stap: maken van een library die meerdere drivers en complexe
% 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