KDE Geolocation Services
johnlayt at googlemail.com
Wed Nov 3 20:42:22 GMT 2010
[Apologies for the cross-post, but I'd like feedback from app developers on
their requirements too, not just core]
This weekend the Marble devs are meeting for a sprint, and I'm tagging along
to discuss a few different issues that I'd like peoples feedback and opinions
The big one is Geolocation services, which more and more apps are making use
of, but which we don't have a central KDE way of accessing, which is leading
to each app implementing it themselves.
The obvious backend solution is Geoclue, a freedesktop.org project which is
available on almost all distro's now, is used by Gnome, and is an official
part of the Meego platform. The problem comes in the api to access Geoclue,
which is a DBus based service with C bindings, as we would obviously prefer a
Qt-ish C++ wrapper for convenience.
Added to this is another issue I want to discuss with Marble: geo-related
astronomical calculations. With at least 4 different places in the SC with
code for sunrise/sunset/moon phases (KHolidays, Plasma dataengine, KStars,
Marble), and my needing them for the astronomical based calendars, it also
seems a good candidate for a shared library somewhere.
We have two possible Geolocation api solutions I know of:
* Roll our own api, possibly in the style of Phonon, using Marble code as a
* Use QtMobility Location api http://doc.qt.nokia.com/qtmobility-1.1.0-beta2/
Given the whole kdelibs vs Qt debate, the obvious duplication, and the choice
app devs will have to make if we roll our own, we do need to consider the Qt
Some of what I know about QtMobility:
* Location api
* Landmarks api
* Maps and Navigation api and widgets, including an Ovi backend
* Full implementation on Win/Mac/Linux as well as the mobile platforms
* Comes packaged with lots of other services that we don't need, such as
Solid, Phonon and kdepim equivalents.
Does anyone have more information?
* Is it likely to be widely shipped on the desktop platforms?
* Will it be monolithic, or could we just pull in the Location part?
Against the Qt option, we obviously already have our own superb geo tools in
Marble that we could work with to produce our own api, but somewhat smaller in
scope than QtMobility or Marble itself:
* basic geo classes like coordinates, location, address etc
* Location api
* Celestial Mechanics api
I suspect most of this would not need to be reliant on any other KDE code, so
mostly could be a pure Qt library in kdesupport and so available for anyone,
although we may need some bits in kdelibs for localization and gui.
I believe Marble already has code (not yet used?) implementing a phonon like
Location abstraction api and a Geoclue backend, and obviously well proven base
geo classes, but we would obviously need to find out if this is a course they
want to follow.
The geo library would not provide navigation or a map widget like QtMobility
does, we would leave that to Marble proper with apps choosing to depend on it
if they want.
We could however provide a basic SVG based country and timezone picker widget
using a data file of around 100k, but depending on who would need it it may be
better off in kdebase where the kcm's are the main use-case I can think of.
A big advantage of our own api could be better integration with other KDE
stuff, such as PIM, e.g. a standard class for addresses that integrates into
Akonadi Contacts and use our KLocale address format setting (bet you didn't
know we had one :-).
So what I'd like to hear is:
* Do we roll our own api, or use QtMobility?
* Does anyone know another option?
* If roll our own, where in the stack does it live: kdesupport, kdelibs,
* Use cases: whether in your app, or just a smart/cool/crazy idea, we need to
know how you would use it, so we can know the requirements
More information about the kde-core-devel