[Development] Touch Points Update

Francisco Ortega franciscoraulortega at gmail.com
Mon Jun 17 14:48:45 CEST 2013


Frederick,

Thank you for your email.
Sorry for delayed replied. I do agree with all your observations/comments.
I hope to get to the code soon, probably sometime in July.

Thank you,
Francisco

Francisco R. Ortega
Ph.D. Candidate in Computer Science
Florida International University
http://www.FranciscoRaulOrtega.com
"No me quieras por que gane, necesito que me quieras para ganar" -- Marcelo
Bielsa


On Mon, Jun 10, 2013 at 3:44 AM, Frederik Gladhorn <
frederik.gladhorn at digia.com> wrote:

> Hello Francisco,
>
> Lørdag 8. juni 2013 13.06.20 skrev Francisco Ortega:
> > Hello all,
> >
> > I spoke to Oliver Wolf this past Monday (6/3/2013) and a few other
> members
> > (#qt-labs) about the qtbase/src/plugins/platforms dealing with Touch.
> Like
> > always, everyone is extremely helpful.
> >
> > I started talking about Windows having a few additional data members for
> a
> > given touch point. Most importantly, I spoke about the unsigned long ID
> > given by windows, which is not the same. Without going into much
> > explanation here, I spoke in IRC that I used that unique ID to store
> touch
> > points to a database to later reply them. The current id for a windows
> app
> > running Qt does not does the same, since it can go from 0,1,2... and
> later
> > 0,1,2,3 in the same moment. As most of you may guess, I could do
> something
> > to fix this for me.
>
> If you store them in a database you can just map your own unique IDs there,
> whenever a touch point appears, assign it a new ID and keep track of it.
> Qt uses consistent IDs.
> As long as  a touch event is ongoing, the ID will stay the same. When a
> finger
> is lifted (lets say IDs 1,2,3 were pressed) and 2 goes away and is
> re-added,
> it will be a new unique ID compared to the others (you might end up with
> 1,3,4).
> I don't see how the actualy unique ID is relevant, you just need to be
> able to
> identify individual points and track them from what I understand.
>
> > However, I was thinking at a larger scale. Therefore, I went and check
> the
> > three platforms that I have accessed to. Windows, Linux (Debian 7), and
> Mac
> > OS X 10.8. Windows is the only platform that I know well.
> >
> > With the search, I found that Linux and MacOSX has what is already given
> by
> > Qt. x,y,state. Linux also has a timestamp, which I didn't no see in
> > QTouchEvents::TouchPoint (in linux is under time, but I think is a
> > timestamp). Windows has the timestamp as well.
>
> What about QInputEvent::timestamp()?
>
> > Windows also has Cx,Cy which is the contact area. Not the most useful
> data
> > at least with my Multi-Touch monitors (3M) because it gives me two
> > values... but nevertheless, a value that is no there.
>
> This might be a good addition, it can go directly into
> QTouchEventTouchPointPrivate (qevent_p.h).
>
> > With all this preamble, I would like to get to the meet of the change
> that
> > I will submit and see if it gets reviewed. First, let me tell you what I
> > discarded. I hope your feedback about all.
> >
> > (First ideas, that I decided not to go for)
> >
> > 1) Returning a void * to a platform structure, it is not a good idea, so
> is
> > out.
> > 2) Changing the current id (int) to unsigned long can have multiple
> > unintended consequences to current code, that is best not to do it. So is
> > out.
> > 3) setting the platform id (windows) to the int by moding with a
> "MAX_INT"
> > does not feel right  to me.
> >
> > What I will change in the code and submit when ready is the following:
> >
> > 1) Create an interface to used a platformSpecificData() that will be the
> > same across all Operating Systems. For example, say that we have
> > data.cxfor mac os x. Then this will simply be 0, the data.flags will
> > specify if
> > the data is available.
> >
> > I hope to receive feedback. I'm not sure if I can do it this month,
> since I
> > have to submit a paper to a conference, but I will try. if not next week.
> > Because the change may be more significant, is probably that even if
> review
> > and accept it, it will take a while to make it to the stable release.
> > However, I think this is the best option.
> >
> > Once again, I thank you for all the feedback and continue support here
> and
> > in Irc.
> >
> > Other contributions in the future that I hope to be involved is the "Leap
> > Motion" which I will be getting soon and some MEMS that I have already
> > received. I like input and please consider me for any work you may need.
>
> Help with the input events is most certainly appreciated :)
> Greetings,
> Frederik
>
>
> >
> > Thanks,
> > Francisco
> >
> >
> > Francisco R. Ortega
> > Ph.D. Candidate in Computer Science
> > Florida International University
> > http://www.FranciscoRaulOrtega.com
> > "No me quieras por que gane, necesito que me quieras para ganar" --
> Marcelo
> > Bielsa
> --
> Best regards,
> Frederik Gladhorn
> Senior Software Engineer - Digia, Qt
> Visit us on: http://qt.digia.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20130617/d5d11679/attachment.html>


More information about the Development mailing list