Skip to content
Projects
Groups
Snippets
Help
Loading...
Help
Support
Keyboard shortcuts
?
Submit feedback
Contribute to GitLab
Sign in
Toggle navigation
M
multitouch
Project overview
Project overview
Details
Activity
Releases
Repository
Repository
Files
Commits
Branches
Tags
Contributors
Graph
Compare
Issues
0
Issues
0
List
Boards
Labels
Milestones
Merge Requests
0
Merge Requests
0
CI / CD
CI / CD
Pipelines
Jobs
Schedules
Analytics
Analytics
CI / CD
Repository
Value Stream
Wiki
Wiki
Members
Members
Collapse sidebar
Close sidebar
Activity
Graph
Create a new issue
Jobs
Commits
Issue Boards
Open sidebar
Taddeüs Kroes
multitouch
Commits
bff901c6
Commit
bff901c6
authored
Jun 18, 2012
by
Taddeüs Kroes
Browse files
Options
Browse Files
Download
Email Patches
Plain Diff
Some linguistic improvements to report.
parent
cc772060
Changes
1
Show whitespace changes
Inline
Side-by-side
Showing
1 changed file
with
32 additions
and
32 deletions
+32
-32
docs/report.tex
docs/report.tex
+32
-32
No files found.
docs/report.tex
View file @
bff901c6
...
...
@@ -241,13 +241,15 @@ goal is to test the effectiveness of the design and detect its shortcomings.
\label
{
sec:areas
}
% TODO: in introduction: gestures zijn opgebouwd uit meerdere primitieven
Touch input devices are unaware of the graphical input widgets rendered on
screen and therefore generate events that simply identify the screen
location at which an event takes place. In order to be able to direct a
gesture to a particular widget on screen, an application programmer must
restrict 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 application developer.
Touch input devices are unaware of the graphical input
widgets
\footnote
{
``Widget'' is a name commonly used to identify an element
of a graphical user interface (GUI).
}
rendered on screen and therefore
generate events that simply identify the screen location at which an event
takes place. In order to be able to direct a gesture to a particular widget
on screen, an application programmer must restrict 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
application developer.
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
...
...
@@ -277,30 +279,28 @@ goal is to test the effectiveness of the design and detect its shortcomings.
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 also 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.
widget that is receiving the gesture.
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 also be made to represent more complex
shapes.
An area groups events and assigns them to gesture detection logic. This
possibly triggers a gesture, which must be handled by the client
application. A common way to handle events in an application is a
``callback'' mechanism: the application developer binds a function to an
event, that is called 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
...
...
@@ -503,7 +503,7 @@ start the GUI main loop in the current thread
\chapter
{
Test applications
}
A reference implementation of the design
is
written in Python. Two test
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,
...
...
Write
Preview
Markdown
is supported
0%
Try again
or
attach a new file
Attach a file
Cancel
You are about to add
0
people
to the discussion. Proceed with caution.
Finish editing this message first!
Cancel
Please
register
or
sign in
to comment