KDE Geolocation Services

[John Layt]

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

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.

John.