[Development] Touch Points Update
franciscoraulortega at gmail.com
Mon Jun 17 14:48:45 CEST 2013
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.
Francisco R. Ortega
Ph.D. Candidate in Computer Science
Florida International University
"No me quieras por que gane, necesito que me quieras para ganar" -- Marcelo
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
> > (#qt-labs) about the qtbase/src/plugins/platforms dealing with Touch.
> > always, everyone is extremely helpful.
> > I started talking about Windows having a few additional data members for
> > 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
> > points to a database to later reply them. The current id for a windows
> > running Qt does not does the same, since it can go from 0,1,2... and
> > 0,1,2,3 in the same moment. As most of you may guess, I could do
> > 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
> is lifted (lets say IDs 1,2,3 were pressed) and 2 goes away and is
> it will be a new unique ID compared to the others (you might end up with
> 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
> > three platforms that I have accessed to. Windows, Linux (Debian 7), and
> > 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
> > 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
> > 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
> > 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
> > 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
> > 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
> > 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
> > 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 :)
> > 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" --
> > Bielsa
> Best regards,
> Frederik Gladhorn
> Senior Software Engineer - Digia, Qt
> Visit us on: http://qt.digia.com
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Development