multi-touch-dev team mailing list archive

[Duncan McGreggor <duncan.mcgreggor@xxxxxxxxxxxxx>]

On 08/23/2010 03:12 PM, Gene Mosher wrote:
>  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.

Good news on this front, Gene -- Chase and Henrik have been working to
separate this in a really good way. Turns out things had already moved
in that direction. As a result of some subtle bugs that popped up,
they've been working more on this.

If they get a chance to break away from coding, maybe they'll give us an
update/issue explanation :-)

> 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's a most generous offer -- thanks. That would be really cool. I'm
hoping to have some time next week or the week after. I can also pass it
on to my team, as they get time.

>> 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

Given all this, you might be interested in attending the Ubuntu
Developer Summit in Orlando at the end of October:
  http://uds.ubuntu.com/
  http://uds.ubuntu.com/participate/community/

There are going to be a great number of sessions on MT/gestures in
Ubuntu (not necessarily all about uTouch). The conference is free, and
participants just need to make arrangements for travel and
accommodation. If you (or anyone else on the list) is interested in
attending and would like to get our hotel group rate, I can get you more
information from our event coordinator.

Good stuff, Gene -- thanks again.

d