KDE Geolocation Services
Aaron J. Seigo
aseigo at kde.org
Thu Nov 4 17:01:05 GMT 2010
On Thursday, November 4, 2010, John Layt wrote:
> On Wednesday 03 November 2010 22:27:11 Aaron J. Seigo wrote:
> > that said, what dependencies does Geoclue have these days? it used to
> > depend on gconf, which would be a highly unfortunate dependency for
> > kdelibs to acquire. it was said a few years (!) back that this dependency
> > would be easy to remove and would likely be. has it been?
> Well, to be slightly clearer, the whole point of having our own phonon-like
> api would be that there would be no hard dependency on any backend, Geoclue
> or otherwise. No Geoclue installed, we try a different backend, perhaps
> having a default hostip fallback. If no backends are available (or can't
> determine your location) you get a null location.
> I've had a poke around, and there still is a partial GConf dependency, but
> apparently only in the Master Provider:
> A quick explanation, Providers are the backends like gpsd or hostip that
> you can query for your location. You can choose to query any one of these
> directly, but the Master Provider implements logic to decide for you which
> is the best one to query. In theory, you don't need to install the Master
> Provider, or indeed any single Provider, if you don't want to (although I
> haven't checked how easy the build system makes this).
> In openSuse at least the Master Provider is packaged separately to
> libgeoclue and the the other Providers, allowing libgeoclue to rely 'only'
> on glib and gobject, leaving the Master Provider to pull in gconf.
> This makes it possible for us to choose not to depend on the Master
> Provider, but the base library only, and implement our own Master Provider
> in our api.
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.
> Our api would already have been deciding which backend to
> call, Geoclue or something else, it would now also have to choose which
> Geoclue backend to call.
that could be a hidden detail that wouldn't need to be exposed in the API? why
does the API need to offer any control over the backend, versus have it
configured at the system level?
> 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.
i just took a look at the install of it, and libQtLocation is also an
independant library with no deps on other parts of QtMobility. it apparently
builds on its own and installs on its own. (at least i was able to do that
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.
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
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43
KDE core developer sponsored by Qt Development Frameworks
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 198 bytes
Desc: This is a digitally signed message part.
More information about the kde-core-devel