On Thursday 04 November 2010 07:23:38 Cyrille Berger Skott wrote: > On Wednesday 03 November 2010, John Layt wrote: > > * Comes packaged with lots of other services that we don't need, such as > > Solid, Phonon and kdepim equivalents. > > It is worth to note that QtMobility is very modular, so you get a different > library for each of the services. And at least on debian, you get one > package per library. In other word, having other services in QtMobility > should not really be an objection to QtLocation.
That's good to know, I kinda assumed it would be given the talk around a more modular Qt. Do you know if it can be broken down even smaller, say just the Location part and not the Mapping/Navigation part? Does anyone know what other distro's plan? Although I guess if we started depending on it they would have to package it, but I'd rather get their input as to any problems they see. [cc: to packagers list, this is just a high-level discussion about possibly using QtMobility for Gelocation services from KDE 4.7 onwards, any comments?] > An other point to consider is that if you intend to build a cross platform > application that would run also on Meego/Symbian, it might be better to use > an already existing service on that device rather than using an other > library (to reduce memory footprint). So unless, a new API provides a > significant advantage, I don't see it gaining users compared to what is > already in Qt. Aye, that's the big point in QtMobility's favour, and the possibility of getting access to the Ovi map services too. Even Torsten says it will be better if mobile is what you're targeting. And the Mobile profile of kdelibs would almost certainly exclude our api as duplication. Our extra library itself would be very light, really a thin wrapper for talking to the same services as QtMobility, but then you may need the Marble Map widget too. However, that ignores our number one use case, desktop apps, a case of the tail wagging the dog right now. The main thing most apps will want is simply the current location, no maps or navigation required, so the full QtLocation may be overkill, Choosing QtMobility also almost feels like a betrayal of the Marble guys as it would inevitably mean apps would choose to use the QtMobility Map and Navigation stuff for compatibility, unless Marble has some feature they really need (Offline mode? OSM?). If Digikam for example had to use QtLocation to manipulate geodata, would they bother with using the Marble map widget? We can do stuff to make them play well together, but it would be a massive loss of mindshare for Marble. I'm not sure QtLocation supports Free/Open map data either, so there's ethical considerations in play too. Then again, the Qt Map widget may be designed for mobile use cases only and may be a usability nightmare on a desktop, it may not integrate that well into our desktop environment, may not have offline data, etc, so apps may well want to use Marble, in which case why bother with QtMobility at all? There's good arguments both ways and I'm genuinely torn. Lots to investigate and discuss this weekend. John. >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
