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 < [email protected]> 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 > >
_______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
