KDE Geolocation Services

[John Layt]

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.