KDE Geolocation Services

[John Layt]

[Apologies for the cross-post, but I'd like feedback from app developers on 
their requirements too, not just core]

Hi,

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 
on.

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 
base
* 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 
option.

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, 
somewhere else?
* 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

Cheers!

John.