KDE Geolocation Services
johnlayt at googlemail.com
Thu Nov 4 16:29:06 GMT 2010
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.
More information about the kde-core-devel