KDE Geolocation Services
johnlayt at googlemail.com
Thu Nov 4 18:21:55 GMT 2010
On Thursday 04 November 2010 17:01:05 Aaron J. Seigo wrote:
> so we'd have to reimplement the core functionality, which leaves us with
> just the geoclue API and the design done for us. the only way this would
> be a win, imho, is if geoclue was already widely deployed on the target
> system. for the desktop, that doesn't seem to be the case (though i do see
> some dependencies on it on my system: google gadgets, gtk's stupidely
> named libwebkit).
> to me, that's just another strike against using geoclue. we'd end up
> putting a layer on top of it to be future proof and gain portability. iow,
> what QtMobility's Location API is doing.
Not quite, the Master Provider is just some code that goes "You want Level 5
Accuracy? OK, I'll try the GPS Provider first, if not found I'll try GSM
Provider, if not...", just calling the same DBus interface as we would. We
would just do that logic ourselves, then still call the Geoclue Provider for
that service. The app would know nothing of this, it doesn't need to.
Even if the GConf stuff was removed, we'd still want our own lightweight
Master Provider just for the backend independence.
So yes, QtMobility and our own api are probably exact functional equivalents
with regard to abstracting away the backend for the Location api, hence posing
it as a head-to-head question.
> > With regards to the roll-our-own vs QtMobility option, I wonder what
> > QtMobility's dependencies are? Is Geoclue a hard dependency, or does it
> > also have its own Master Provider concept making Geoclue optional?
> it doesn't seem to be a hard dep; there seem to be target-specific (e.g.
> maemo5, maemo6, symbian, etc) providers that get compiled in as
Having backends that work on all supported platforms is probably QtMobility's
greatest strength, it's a no-brainer for anyone wanting an app that provides
location or maps on all Nokia's mobiles.
However, I'd point out the obvious here, if Geoclue requires GConf, and
QtMobility uses Geoclue as its backend on desktops, and we hard depend on
QtMobility, we're still left practically with a hard depend on GConf (unless
QtMobility doesn't need the Master Provider).
I need to investigate what QtMobility does on desktops (Win and Mac too) if
Geoclue isn't available. It looks like the Ovi backend isn't an option due to
the current license. If QtMobility doesn't provide any other backend on
desktop then we would have to code our own, which QtMobility seems to allow.
Time to go code diving. +1 to Open Source :-)
Anyway, working through all the options and implications is just part of the
decision process, I'll be doing a wiki page summarising all the pro's & con's
and implications at the end of it.
> the Landmarks issues that Torsten raises seem valid. perhaps we should
> start talking with the people working on libQtLocation and see if we can't
> make this into exactly what we all need and want, as that seems like it
> could be the best route (excuse the pun ;) if we can get some things
> ironed out.
They follow different approaches, I haven't looked at them much, but it seems
closely tied to the Ovi services and licences would need sorting out.
Personally I see this as a lower priority, more apps will want to know where
they are than what's near-by. Free data services will be an issue in the Map
and Navigation api/widgets too.
> as an aside, the fact that something in Qt *Mobility* is of interest to
> desktop, etc. just underscores for me how utterly naive the idea of "this
> is for mobile, this is for desktop, this is for.." is. yes, some GUI
> differences exist. but beyond that a computer is a computer and it's all
> one big spectrum of capabilities. QtMobility is a stupid label imho, as
> would a QtDesktop module be.
+1000. :-) The fact all the desktop platforms are supported as Tier 2 for
most of the libs means they should have gone for QtPlatform.
More information about the kde-core-devel