multi-touch-dev team mailing list archive

[Gene Mosher <genemosher@xxxxxxxxx>]

 On 8/23/2010 10:40 AM, Duncan McGreggor wrote:
> Hi Gene!
>
> Thanks for your email! I'm cleaning out my inbox, and in the rush of
> last week's announcement, am discovering mails that I hadn't seen, so
> apologies for the late reply :-)
>> I've been using touchscreens for almost 30 years.
> That's a bit of an understatement, isn't it? ;-) You invented of the
> point of sale touchscreen! (Unless I have the wrong Gene Mosher in mind...)
One & the same.
>> Does your team's touchscreen code differentiate between a mouse click
>> versus a touch on any given graphical pixel?  I hope so.  Thanks.
>>
>> Gene Mosher, ViewTouch
> For our release in October, we had to make some sacrifices due to the
> limited time we had available to us. One of the decisions we made was to
> re-use the single-click from X for the single-touch tap "gesture".
>
> However, now that we are using this with other applications, we're
> starting to discover use cases where we'd like to intercept even single
> taps and do some pre-processing. That's impossible right now, but we're
> exploring ways in which we could make this work in our next release
> cycle (in 6 months). The simultaneous support of mouse clicks makes this
> a little bit tricky.
IMO there absolutely needs to be differentiation between any mouse event
and any touch event.  When we're building restaurant menus we use
touches to navigate among the different screens and we use mouse events
(3 buttons) to carry out editing operations on the page itself.  Left
mouse click grabs a button to move it around the page, center click
stretches edges/corners of buttons and right clock opens a dialog box to
make adjustments to appearance properties (surface/edge type/textures),
button name, price, group ID, and so forth.

Without the ability to use the touchscreen to navigate the pages without
regard to whether we're in edit mode or not then we would have to exit
the edit mode and navigate with the mouse, then return to edit mode for
mouse-driven button editing as just mentioned.

I can provide the ViewTouch executable (Debian, Ubuntu) to anyone who is
interested so that they can see this for themselves. 
> That being said, we'd love to hear your thoughts on the matter, as that
> would provide much deeper insight that we could integrate into our
> discussions. Feel free to reply-all; I've cc'ed our MT mail list and
> will approve your email (as a non-subscriber, it will get queued for
> moderation).
>
> Thanks again,
> d
ViewTouch is an application-specific X Window Manager.  It could also be
used to develop a general purpose X Window Manager for touchscreen
apps.  It's a bit dated but I'm all for allowing it to be turned into
Free Software if the POS stuff can be refactored into a separate
binary.  It's very small - only 6.5 Mb in RAM.  and it is written to
Xlib.  Certain improvements in the code would make it up to date while
making it more useful to anyone.  Core fonts should be replaced with
FreeType fonts and XCB could be used, too.  Dynamic loading/unloading of
textures would be nice.  The way ViewTouch saves data avoids messing
with RDBMS, too.  These days Cairo & OpenGL would be big improvements -
this was written in '95-'97 when Xlib was about all we had.

I have lots of ideas but am not a programmer except to the extent that
ViewTouch itself is a graphical programming environment.  The big
advantage to ViewTouch, though, is that it makes full use of X
forwarding for remote users.  Very simple to do, of course, by enabling
TCP listen & SSH and I think everyone would be surprised how well it
works for remote workgroups.  It's very fast.  The speed makes it
possible for us to adapt ViewTouch into a tool to build graphical
languages that people could use to communicate with and work together
with regardless of their spoken languages.  We did this for people
working in restaurants 25 years ago - we could do it for people in all
kinds of situations.

The GUI is a window of opportunity that will never close - it is in some
ways the only real issue in software/hardware.  I would like to help as
long as everyone remembers I'm not a programmer, not in C or C++ or even
Perl, which is what the functionality of ViewTouch is written in.  Since
ViewTouch is primarily just a GUI then it doesn't matter what languages
provide the code behind the scenes, of course.

Thanks, Duncan and others.

Gene Mosher