Hi Till, >-----Original Message----- >From: qt-mobility-feedback-boun...@trolltech.com [mailto:qt-mobility- >feedback-boun...@trolltech.com] On Behalf Of ext Till Harbaum / Lists
>On Monday, October 04, 2010 02:55:50 david.la...@nokia.com wrote: >> That assumes that the user has gpsd installed and that it's the >preferred >> method of abstraction to use for accessing GPS on linux systems. >Don't you think a little pragmatism may be useful here? You want people >to use >qtmobility, don't you? And gpsd is the way to access a gps on an >ordinary >linux pc today. Today, everybody having a working gps setup on a desktop >linux >has a running gpsd. Why not exploit this? As David pointed out there are potentially multiple sources and the device name is not always standardized. Therefore we didn't feel that hard coding would be appropriate. What might work on your desktop may not be a universal truth. Therefore we opted for the middle ground. While it is not generalized enough for *all* desktops there is a pretty good starting point. By the way the QNMEAPositionInfoSource works with Windows based NMEA devices too. At this point your suggestion does break without further API changes. Please keep in mind that Mobility does put focus on the Mobile platforms at this stage. From this point of view there is quite a bit of pragmatism in the code already. A lot of other Mobility API's don't have any desktop support. Desktop support takes effort and time too. This does not mean we won't support Desktops. On the contrary we still ensure that an API remains implementable on desktops and are likely to bring the desktops to a conclusion at a later stage. Of course we are open to speeding this process up via external contributions. >> At present the positioning part of the Location API is only supported >on >> desktop platforms via QNmeaPositionInfoSource, since the data could be >> coming from /dev/gps, from a Bluetooth device, or from pretty much >Has anyone actually ever tested this with a real nmea device? It's not >working >for me and the lightmaps example is broken in a way that it just can't >work. While I wouldn't rule out that there is a bug in light maps the QNmeaPositionInfoSource is tested. In fact, it is the fall back alternative for each example if the platform doesn't have a default source. Also looking at the code the satellite info source component it is clearly optional. Again the NMEA file fallback would hit the same code path. Yes, if you have a real NMEA source you have to change a couple of lines of code to point to your device but that should be it. LBNL I would not rule out that your NMEA source may have a slightly different NMEA output which may lead to an parse error. You could easily verify this by comparing the nmealog.txt with output from your device. This would be a bug. LBNL we do not support NMEA 2000. -- Alex _______________________________________________ Qt-mobility-feedback mailing list Qt-mobility-feedback@trolltech.com http://lists.trolltech.com/mailman/listinfo/qt-mobility-feedback
