[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. >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
