|
|
@@ -2,7 +2,7 @@
|
|
|
|
|
|
\usepackage[english]{babel}
|
|
|
\usepackage[utf8]{inputenc}
|
|
|
-\usepackage{hyperref,graphicx,float,tikz}
|
|
|
+\usepackage{hyperref,graphicx,tikz,subfigure}
|
|
|
|
|
|
% Link colors
|
|
|
\hypersetup{colorlinks=true,linkcolor=black,urlcolor=blue,citecolor=DarkGreen}
|
|
|
@@ -29,19 +29,19 @@
|
|
|
\tableofcontents
|
|
|
|
|
|
\chapter{Introduction}
|
|
|
+\label{chapter:introduction}
|
|
|
|
|
|
Surface-touch devices have evolved from pen-based tablets to single-touch
|
|
|
trackpads, to multi-touch devices like smartphones and tablets. Multi-touch
|
|
|
devices enable a user to interact with software using hand gestures, making the
|
|
|
interaction more expressive and intuitive. These gestures are more complex than
|
|
|
primitive ``click'' or ``tap'' events that are used by single-touch devices.
|
|
|
-Some examples of more complex gestures are so-called ``pinch''\footnote{A
|
|
|
-``pinch'' gesture is formed by performing a pinching movement with multiple
|
|
|
-fingers on a multi-touch surface. Pinch gestures are often used to zoom in or
|
|
|
-out on an object.} and ``flick''\footnote{A ``flick'' gesture is the act of
|
|
|
-grabbing an object and throwing it in a direction on a touch surface, giving
|
|
|
-it momentum to move for some time after the hand releases the surface.}
|
|
|
-gestures.
|
|
|
+Some examples of more complex gestures are ``pinch''\footnote{A ``pinch''
|
|
|
+gesture is formed by performing a pinching movement with multiple fingers on a
|
|
|
+multi-touch surface. Pinch gestures are often used to zoom in or out on an
|
|
|
+object.} and ``flick''\footnote{A ``flick'' gesture is the act of grabbing an
|
|
|
+object and throwing it in a direction on a touch surface, giving it momentum to
|
|
|
+move for some time after the hand releases the surface.} gestures.
|
|
|
|
|
|
The complexity of gestures is not limited to navigation in smartphones. Some
|
|
|
multi-touch devices are already capable of recognizing objects touching the
|
|
|
@@ -60,32 +60,34 @@ gestures in an application.
|
|
|
|
|
|
The main question in this research project is whether a generic architecture
|
|
|
for the detection of complex interaction gestures can be designed, with the
|
|
|
-capability of managing the complexity of gesture detection logic.
|
|
|
+capability of managing the complexity of gesture detection logic. The ultimate
|
|
|
+goal would be to create an implementation of this architecture that can be
|
|
|
+extended to support a wide range of complex gestures. With the existence of
|
|
|
+such an implementation, application developers do not need to reinvent gesture
|
|
|
+detection for every new gesture-based application.
|
|
|
|
|
|
Application frameworks for surface-touch devices, such as Nokia's Qt \cite{qt},
|
|
|
-include the detection of commonly used gestures like \emph{pinch} gestures.
|
|
|
-However, this detection logic is dependent on the application framework.
|
|
|
-Consequently, an application developer who wants to use multi-touch interaction
|
|
|
-in an application is forced to choose an application framework that includes
|
|
|
-support for multi-touch gestures. Therefore, a requirement of the generic
|
|
|
-architecture is that it must not be bound to a specific application framework.
|
|
|
-Moreover, the set of supported gestures is limited by the application framework
|
|
|
-of choice. To incorporate a custom event in an application, the application
|
|
|
-developer needs to extend the framework. This requires extensive knowledge of
|
|
|
-the framework's architecture. Also, if the same gesture is used in another
|
|
|
-application that is based on another framework, the detection logic has to be
|
|
|
-translated for use in that framework. Nevertheless, application frameworks are
|
|
|
-a necessity when it comes to fast, cross-platform development. Therefore, the
|
|
|
-architecture design should aim to be compatible with existing frameworks, but
|
|
|
-provide a way to detect and extend gestures independent of the framework.
|
|
|
-
|
|
|
-An application framework is written in a specific programming language. A
|
|
|
-generic architecture should not limited to a single programming language. The
|
|
|
-ultimate goal of this thesis is to provide support for complex gesture
|
|
|
-interaction in any application. Thus, applications should be able to address
|
|
|
-the architecture using a language-independent method of communication. This
|
|
|
-intention leads towards the concept of a dedicated gesture detection
|
|
|
-application that serves gestures to multiple programs at the same time.
|
|
|
+do already include the detection of commonly used gestures like \emph{pinch}
|
|
|
+gestures. However, this detection logic is dependent on the application
|
|
|
+framework. Consequently, an application developer who wants to use multi-touch
|
|
|
+interaction in an application is forced to use an application framework that
|
|
|
+includes support for multi-touch gestures. Moreover, the set of supported
|
|
|
+gestures is limited by the application framework of choice. To incorporate a
|
|
|
+custom event in an application, the application developer needs to extend the
|
|
|
+framework. This requires extensive knowledge of the framework's architecture.
|
|
|
+Also, if the same gesture is needed in another application that is based on
|
|
|
+another framework, the detection logic has to be translated for use in that
|
|
|
+framework. Nevertheless, application frameworks are a necessity when it comes
|
|
|
+to fast, cross-platform development. A generic architecture design should aim
|
|
|
+to be compatible with existing frameworks, and provide a way to detect and
|
|
|
+extend gestures independent of the framework.
|
|
|
+
|
|
|
+Application frameworks are written in a specific programming language. To
|
|
|
+support multiple frameworks and programming languages, the architecture should
|
|
|
+be accessible for applications using a language-independent method of
|
|
|
+communication. This intention leads towards the concept of a dedicated gesture
|
|
|
+detection application that serves gestures to multiple applications at the same
|
|
|
+time.
|
|
|
|
|
|
The scope of this thesis is limited to the detection of gestures on multi-touch
|
|
|
surface devices. It presents a design for a generic gesture detection
|
|
|
@@ -93,10 +95,6 @@ architecture for use in multi-touch based applications. A reference
|
|
|
implementation of this design is used in some test case applications, whose
|
|
|
goal is to test the effectiveness of the design and detect its shortcomings.
|
|
|
|
|
|
-% FIXME: Moet deze nog in de introductie?
|
|
|
-% How can the input of the architecture be normalized? This is needed, because
|
|
|
-% multi-touch drivers use their own specific message format.
|
|
|
-
|
|
|
\section{Structure of this document}
|
|
|
|
|
|
% TODO: pas als thesis af is
|
|
|
@@ -137,9 +135,7 @@ goal is to test the effectiveness of the design and detect its shortcomings.
|
|
|
|
|
|
An important observation in this application is that different gestures are
|
|
|
detected by different gesture trackers, thus separating gesture detection
|
|
|
- code into maintainable parts. The architecture has adopted this design
|
|
|
- feature by also using different gesture trackers to track different gesture
|
|
|
- types.
|
|
|
+ code into maintainable parts.
|
|
|
|
|
|
% TODO: This is not really 'related', move it to somewhere else
|
|
|
\section{Processing implementation of simple gestures in Android}
|
|
|
@@ -213,13 +209,13 @@ goal is to test the effectiveness of the design and detect its shortcomings.
|
|
|
After all, the gesture detection logic in a ``generic'' architecture should
|
|
|
not be implemented based on driver-specific messages. The event types in
|
|
|
this format should be chosen so that multiple drivers can trigger the same
|
|
|
- events. If each supported driver adds its own set of event types to the
|
|
|
- common format, it the purpose of being ``common'' would be defeated.
|
|
|
+ events. If each supported driver would add its own set of event types to
|
|
|
+ the common format, it the purpose of being ``common'' would be defeated.
|
|
|
|
|
|
- A reasonable expectation for a touch device driver is that it detects
|
|
|
- simple touch points, with a ``point'' being an object at an $(x, y)$
|
|
|
- position on the touch surface. This yields a basic set of events:
|
|
|
- $\{point\_down, point\_move, point\_up\}$.
|
|
|
+ A minimal expectation for a touch device driver is that it detects simple
|
|
|
+ touch points, with a ``point'' being an object at an $(x, y)$ position on
|
|
|
+ the touch surface. This yields a basic set of events: $\{point\_down,
|
|
|
+ point\_move, point\_up\}$.
|
|
|
|
|
|
The TUIO protocol supports fiducials\footnote{A fiducial is a pattern used
|
|
|
by some touch devices to identify objects.}, which also have a rotational
|
|
|
@@ -236,9 +232,10 @@ goal is to test the effectiveness of the design and detect its shortcomings.
|
|
|
components in the architecture for translation to gestures. This
|
|
|
communication flow is illustrated in figure \ref{fig:driverdiagram}.
|
|
|
|
|
|
- A touch device driver can be supported by adding an event driver
|
|
|
- implementation for it. The event driver implementation that is used in an
|
|
|
- application is dependent of the support of the touch device.
|
|
|
+ Support for a touch device driver can be added by adding an event driver
|
|
|
+ implementation. The choice of event driver implementation that is used in an
|
|
|
+ application is dependent on the driver support of the touch device being
|
|
|
+ used.
|
|
|
|
|
|
\driverdiagram{Extension of the diagram from figure \ref{fig:basicdiagram},
|
|
|
showing the position of the event driver in the architecture. The event
|
|
|
@@ -246,7 +243,8 @@ goal is to test the effectiveness of the design and detect its shortcomings.
|
|
|
delegated to analysis components that will interpret them as more complex
|
|
|
gestures.}
|
|
|
|
|
|
- \section{Restricting gestures to a screen area}
|
|
|
+ \section{Restricting events to a screen area}
|
|
|
+ \label{sec:restricting-gestures}
|
|
|
|
|
|
% TODO: in introduction: gestures zijn opgebouwd uit meerdere primitieven
|
|
|
Touch input devices are unaware of the graphical input widgets rendered on
|
|
|
@@ -255,29 +253,119 @@ goal is to test the effectiveness of the design and detect its shortcomings.
|
|
|
gesture to a particular widget on screen, an application programmer must
|
|
|
restrict the occurrence of a gesture to the area of the screen covered by
|
|
|
that widget. An important question is if the architecture should offer a
|
|
|
- solution to this problem, or leave it to the programmer to assign gestures
|
|
|
- to a widget.
|
|
|
-
|
|
|
- % TODO: eerst: aan developer overlaten, verwijzen naar vorige diagram dan:
|
|
|
- % consider the following example: ... twee vierkantjes die allebei naar
|
|
|
- % rotatie luisteren (figuur ter illustratie): als je ze tegelijk roteert
|
|
|
- % treedt er maar één globaal event op. Dus: niet gestures beperken tot een
|
|
|
- % area, maar events. dan kun je op elk vierkant een aparte detection logic
|
|
|
- % zetten met als input de events op die locatie oftewel: je kan het niet
|
|
|
- % aan de developer overlaten omdat de input van de detection logic moet
|
|
|
- % veranderen (heeft developer geen invloed op) dus conclusie: Je moet
|
|
|
- % events kunnen beperken tot een "area" van het scherm. op dit moment kan
|
|
|
- % de diagram dus al worden uitgebreid
|
|
|
-
|
|
|
- % dan: simpelste aanpak is een lijst van area's, als event erin past dan
|
|
|
+ solution to this problem, or leave it to the application developer to
|
|
|
+ assign gestures to a widget.
|
|
|
+
|
|
|
+ The latter case generates a problem when a gesture must be able to occur at
|
|
|
+ different screen positions at the same time. Consider the example in figure
|
|
|
+ \ref{fig:ex1}, where two squares must be able to be rotated independently
|
|
|
+ at the same time. If the developer is left the task to assign a gesture to
|
|
|
+ one of the squares, the event analysis component in figure
|
|
|
+ \ref{fig:driverdiagram} receives all events that occur on the screen.
|
|
|
+ Assuming that the rotation detection logic detects a single rotation
|
|
|
+ gesture based on all of its input events, without detecting clusters of
|
|
|
+ input events, only one rotation gesture can be triggered at the same time.
|
|
|
+ When a user attempts to ``grab'' one rectangle with each hand, the events
|
|
|
+ triggered by all fingers are combined to form a single rotation gesture
|
|
|
+ instead of two separate gestures.
|
|
|
+
|
|
|
+ \examplefigureone
|
|
|
+
|
|
|
+ To overcome this problem, groups of events must be separated by the event
|
|
|
+ analysis component before any detection logic is executed. An obvious
|
|
|
+ solution for the given example is to incorporate this separation in the
|
|
|
+ rotation detection logic itself, using a distance threshold that decides if
|
|
|
+ an event should be added to an existing rotation gesture. Leaving the task
|
|
|
+ of separating groups of events to detection logic leads to duplication of
|
|
|
+ code. For instance, if the rotation gesture is replaced by a \emph{pinch}
|
|
|
+ gesture that enlarges a rectangle, the detection logic that detects the
|
|
|
+ pinch gesture would have to contain the same code that separates groups of
|
|
|
+ events for different gestures. Also, a pinch gesture can be performed using
|
|
|
+ fingers multiple hands as well, in which case the use of a simple distance
|
|
|
+ threshold is insufficient. These examples show that gesture detection logic
|
|
|
+ is hard to implement without knowledge about (the position of) the
|
|
|
+ widget\footnote{``Widget'' is a name commonly used to identify an element
|
|
|
+ of a graphical user interface (GUI).} that is receiving the gesture.
|
|
|
+
|
|
|
+ Therefore, a better solution for the assignment of events to gesture
|
|
|
+ detection is to make the gesture detection component aware of the locations
|
|
|
+ of application widgets on the screen. To accomplish this, the architecture
|
|
|
+ must contain a representation of the screen area covered by a widget. This
|
|
|
+ leads to the concept of an \emph{area}, which represents an area on the
|
|
|
+ touch surface in which events should be grouped before being delegated to a
|
|
|
+ form of gesture detection. Examples of simple area implementations are
|
|
|
+ rectangles and circles. However, area's could be made to represent more
|
|
|
+ complex shapes.
|
|
|
+
|
|
|
+ An area groups events and assigns them to some piece of gesture detection
|
|
|
+ logic. This possibly triggers a gesture, which must be handled by the
|
|
|
+ client application. A common way to handle framework events in an
|
|
|
+ application is a ``callback'' mechanism: the application developer binds a
|
|
|
+ function to an event, that is called by the framework when the event
|
|
|
+ occurs. Because of the familiarity of this concept with developers, the
|
|
|
+ architecture uses a callback mechanism to handle gestures in an
|
|
|
+ application. Since an area controls the grouping of events and thus the
|
|
|
+ occurrence of gestures in an area, gesture handlers for a specific gesture
|
|
|
+ type are bound to an area. Figure \ref{fig:areadiagram} shows the position
|
|
|
+ of areas in the architecture.
|
|
|
+
|
|
|
+ \areadiagram{Extension of the diagram from figure \ref{fig:driverdiagram},
|
|
|
+ showing the position of areas in the architecture. An area delegate events
|
|
|
+ to a gesture detection component that trigger gestures. The area then calls
|
|
|
+ the handler that is bound to the gesture type by the application.}
|
|
|
+
|
|
|
+ Note that the boundaries of an area are only used to group events, not
|
|
|
+ gestures. A gesture could occur outside the area that contains its
|
|
|
+ originating events, as illustrated by the example in figure \ref{fig:ex2}.
|
|
|
+
|
|
|
+ \examplefiguretwo
|
|
|
+
|
|
|
+ A remark must be made about the use of areas to assign events the detection
|
|
|
+ of some gesture. The concept of an ``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. This is a
|
|
|
+ reasonable assumption for simple touch objects whose only parameter is a
|
|
|
+ position, such as a pen or a human finger. However, more complex touch
|
|
|
+ objects can have additional parameters, such as rotational orientation or
|
|
|
+ color. An even more generic concept is the \emph{event filter}, which
|
|
|
+ detects whether an event should be assigned to a particular piece of
|
|
|
+ gesture detection based on all available parameters. This level of
|
|
|
+ abstraction allows for constraints like ``Use all blue objects within a
|
|
|
+ widget for rotation, and green objects for tapping.''. As mentioned in the
|
|
|
+ introduction chapter [\ref{chapter:introduction}], the scope of this thesis
|
|
|
+ is limited to multi-touch surface based devices, for which the \emph{area}
|
|
|
+ concept suffices. Section \ref{sec:eventfilter} explores the possibility of
|
|
|
+ areas to be replaced with event filters.
|
|
|
+
|
|
|
+ \subsection*{Reserving an event for a gesture}
|
|
|
+
|
|
|
+ The most simple implementation of areas in the architecture is a list of
|
|
|
+ areas. When the event driver delegates an event, it is delegated to gesture
|
|
|
+ detection by each area that contains the event coordinates. A problem
|
|
|
+ occurs when areas overlap, as shown by figure \ref{fig:ex3}. When the
|
|
|
+ white rectangle is rotated, the gray square should keep its current
|
|
|
+ orientation. This means that events that are used for rotation of the white
|
|
|
+ square, should not be used for rotation of the gray square. To achieve
|
|
|
+ this, there must be some communication between the rotation detection
|
|
|
+ components of the two squares.
|
|
|
+
|
|
|
+ \examplefigurethree
|
|
|
+
|
|
|
+ a
|
|
|
+
|
|
|
+ --------
|
|
|
+
|
|
|
+ % simpelste aanpak is een lijst van area's, als event erin past dan
|
|
|
% delegeren. probleem (aangeven met voorbeeld van geneste widgets die
|
|
|
% allebei naar tap luisteren): als area's overlappen wil je bepaalde events
|
|
|
% reserveren voor bepaalde stukjes detection logic
|
|
|
+
|
|
|
% oplossing: area'a opslaan in boomstructuur en event propagatie gebruiken
|
|
|
% -> area binnenin een parent area kan events propageren naar die parent,
|
|
|
% detection logic kan propagatie tegenhouden. om omhoog in de boom te
|
|
|
% propageren moet het event eerst bij de leaf aankomen, dus eerst delegatie
|
|
|
% tot laagste leaf node die het event bevat.
|
|
|
+
|
|
|
% speciaal geval: overlappende area's in dezelfde laag v/d boom. in dat
|
|
|
% geval: area die later is toegevoegd (rechter sibling) wordt aangenomen
|
|
|
% bovenop de sibling links ervan te liggen en krijgt dus eerst het event.
|
|
|
@@ -288,37 +376,16 @@ goal is to test the effectiveness of the design and detect its shortcomings.
|
|
|
% die voor widgets een boomstructuur gebruikt -> voor elke widget die touch
|
|
|
% events heeft een area aanmaken
|
|
|
|
|
|
- Gestures are composed of primitive events using detection logic. If a
|
|
|
- particular gesture should only occur within some area of the screen, it
|
|
|
- should be composed of only events that occur within that area Events that
|
|
|
- occur outside the area are not likely to be relevant to the . In other
|
|
|
- words, the gesture detection logic is affected by the area in which the
|
|
|
- gestures should be detected. Since the detection logic is part of the
|
|
|
- architecture, the architecture must be able to restrict the set of events
|
|
|
- to that are delegated to the particular piece of detection logic for the
|
|
|
- gesture being detected in the area.
|
|
|
-
|
|
|
- For example, a button tap\footnote{A ``tap'' gesture is triggered when a
|
|
|
- touch object releases a touch surface within a certain time and distance
|
|
|
- from the point where it initially touched the surface.} should only occur
|
|
|
- on the button itself, and not in any other area of the screen. A solution
|
|
|
- to this problem is the use of \emph{widgets}. The button from the example
|
|
|
- can be represented as a rectangular widget with a position and size. The
|
|
|
- position and size are compared with event coordinates to determine whether
|
|
|
- an event should occur within the button.
|
|
|
-
|
|
|
- \subsection*{Callbacks}
|
|
|
- \label{sec:callbacks}
|
|
|
-
|
|
|
- When an event is propagated by a widget, it is first used for event
|
|
|
- analysis on that widget. The event analysis can then trigger a gesture
|
|
|
- in the widget, which has to be handled by the application. To handle a
|
|
|
- gesture, the widget should provide a callback mechanism: the
|
|
|
- application binds a handler for a specific type of gesture to a widget.
|
|
|
- When a gesture of that type is triggered after event analysis, the
|
|
|
- widget triggers the callback.
|
|
|
-
|
|
|
- \subsection*{Widget tree}
|
|
|
+ %For example, a button tap\footnote{A ``tap'' gesture is triggered when a
|
|
|
+ %touch object releases a touch surface within a certain time and distance
|
|
|
+ %from the point where it initially touched the surface.} should only occur
|
|
|
+ %on the button itself, and not in any other area of the screen. A solution
|
|
|
+ %to this problem is the use of \emph{widgets}. The button from the example
|
|
|
+ %can be represented as a rectangular widget with a position and size. The
|
|
|
+ %position and size are compared with event coordinates to determine whether
|
|
|
+ %an event should occur within the button.
|
|
|
+
|
|
|
+ \subsection*{Area tree}
|
|
|
|
|
|
A problem occurs when widgets overlap. If a button in placed over a
|
|
|
container and an event occurs occurs inside the button, should the
|
|
|
@@ -347,34 +414,25 @@ goal is to test the effectiveness of the design and detect its shortcomings.
|
|
|
\texttt{GtkTouchWidget} that synchronises the position of a touch
|
|
|
widget with that of a GTK widget, using GTK signals.
|
|
|
|
|
|
- \subsection*{Position of widget tree in architecture}
|
|
|
-
|
|
|
- \widgetdiagram{Extension of the diagram from figure
|
|
|
- \ref{fig:driverdiagram}, showing the position of widgets in the
|
|
|
- architecture.}
|
|
|
+ \section{Detecting gestures from events}
|
|
|
+ \label{sec:gesture-detection}
|
|
|
|
|
|
- \section{Event analysis}
|
|
|
- \label{sec:event-analysis}
|
|
|
+ The events that are grouped by areas must be translated to complex gestures
|
|
|
+ in some way. This analysis is specific to the type of gesture being
|
|
|
+ detected. E.g. the detection of a ``tap'' gesture is very different from
|
|
|
+ detection of a ``rotate'' gesture. The architecture has adopted the
|
|
|
+ \emph{gesture tracker}-based design described by \cite{win7touch}, which
|
|
|
+ separates the detection of different gestures into different \emph{gesture
|
|
|
+ trackers}. This keeps the different pieces of gesture detection code
|
|
|
+ manageable and extendable. A single gesture tracker detects a specific set
|
|
|
+ of gesture types, given a set of primitive events. An example of a possible
|
|
|
+ gesture tracker implementation is a ``transformation tracker'' that detects
|
|
|
+ rotation, scaling and translation gestures.
|
|
|
|
|
|
- % TODO: essentie moet zijn dat gesture trackers detection logic opdelen in
|
|
|
- % behapbare stukken, en worden toegewezen aan een enkele area waardoor er
|
|
|
- % meerdere trackers tegelijk kunnen draaien op verschillende delen v/h
|
|
|
- % scherm. een formele definitie van gestures zou wellicht beter zijn, maar
|
|
|
+ % TODO: een formele definitie van gestures zou wellicht beter zijn, maar
|
|
|
% wordt niet gegeven in deze thesis (wel besproken in future work)
|
|
|
|
|
|
- The events that are delegated to widgets must be analyzed in some way to
|
|
|
- gestures. This analysis is specific to the type of gesture being detected.
|
|
|
- E.g. the detection of a ``tap'' gesture is very different from detection of
|
|
|
- a ``rotate'' gesture. The implementation described in \cite{win7touch}
|
|
|
- separates the detection of different gestures into different \emph{gesture
|
|
|
- trackers}. This keeps the different pieces of detection code managable and
|
|
|
- extandable. Therefore, the architecture also uses gesture trackers to
|
|
|
- separate the analysis of events. A single gesture tracker detects a
|
|
|
- specific set of gesture types, given a sequence of events. An example of a
|
|
|
- possible gesture tracker implementation is a ``transformation tracker''
|
|
|
- that detects rotation, scaling and translation gestures.
|
|
|
-
|
|
|
- \subsection*{Assignment of a gesture tracker to a widget}
|
|
|
+ \subsection*{Assignment of a gesture tracker to an area}
|
|
|
|
|
|
As explained in section \ref{sec:callbacks}, events are delegated from
|
|
|
a widget to some event analysis. The analysis component of a widget
|
|
|
@@ -404,7 +462,8 @@ goal is to test the effectiveness of the design and detect its shortcomings.
|
|
|
The button is located inside an application window, which can be resized
|
|
|
using pinch gestures.
|
|
|
|
|
|
- % TODO: comments weg, in pseudocode opschrijven
|
|
|
+ % TODO: comments weg, in pseudocode opschrijven, uitbreiden met draggable
|
|
|
+ % circle en illustrerende figuur
|
|
|
\begin{verbatim}
|
|
|
initialize GUI, creating a window
|
|
|
|
|
|
@@ -442,6 +501,13 @@ goal is to test the effectiveness of the design and detect its shortcomings.
|
|
|
|
|
|
\chapter{Test applications}
|
|
|
|
|
|
+\section{Reference implementation in Python}
|
|
|
+\label{sec:implementation}
|
|
|
+
|
|
|
+% TODO
|
|
|
+% alleen window.contains op point down, niet move/up
|
|
|
+% een paar simpele windows en trackers
|
|
|
+
|
|
|
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
|
|
|
@@ -449,6 +515,8 @@ 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
|
|
|
@@ -461,6 +529,10 @@ for details).
|
|
|
% bijv. een state machine
|
|
|
% - volgende stap: maken van een library die meerdere drivers en complexe
|
|
|
% gestures bevat
|
|
|
+% - "event filter" ipv "area"
|
|
|
+
|
|
|
+\section{A generic way for grouping events}
|
|
|
+\label{sec:eventfilter}
|
|
|
|
|
|
\bibliographystyle{plain}
|
|
|
\bibliography{report}{}
|
|
|
@@ -567,11 +639,4 @@ algorithms based on its test program.
|
|
|
Also, the different detection algorithms are all implemented in the same file,
|
|
|
making it complex to read or debug, and difficult to extend.
|
|
|
|
|
|
-\chapter{Reference implementation in Python}
|
|
|
-\label{app:implementation}
|
|
|
-
|
|
|
-% TODO
|
|
|
-% alleen window.contains op point down, niet move/up
|
|
|
-% een paar simpele windows en trackers
|
|
|
-
|
|
|
\end{document}
|
Taddeus Kroes