[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: Geolocation module
From:       John Layt <jlayt () kde ! org>
Date:       2014-02-20 17:12:09
Message-ID: 21433703.p96Im1GAno () ithaca ! layt ! net
[Download RAW message or body]

On Wednesday 19 Feb 2014 11:22:36 Zeeshan Ali wrote:
> Hi John,

> > Yes for Qt5.2 onwards the new QtLocation module is the option I
> > recommend for general use in KDE Generation 5, as it is just the
> > location services api without the mapping api and so is now very
> > lightweight, i.e. doesn't pull in Qt3D when all you want to know is
> > what country you are in.  It currently only uses Geoclue 1, but the
> > maintainer is aware of Geoclue 2 and it is on his feature list to
> > implement support.

> Thats good news. geoclue1 is not just unmaintained (which it has been
> for a while), the whole repo has been ripped off to really start from
> scratch for geoclue2. So at this point, I will strongly recommend to
> port away from it.

I believe he plans to implement a separate plugin for Geoclue2, but I don't 
see any new code in the Qt 5.3 release which went into feature freeze this 
week.  It would be good if someone from KDE volunteers to submit one for the 
next release as we will need to use it (Alexander Blasche is the maintainer 
and would welcome the help as he has a lot on his plate).

> > Note that it is not recommended to use Geoclue directly in KDE apps as
> > it is platform dependent,
> 
> Is it? We do have platform specific components but Ryan Lortie
> recently made it possible to build geoclue without platform-specific
> backends. Although this means that you'll only get geoip-based
> (city-level accuracy) but still, it should now work on *BSD at least.

For us, platform independence means more than just *BSD, it includes platforms 
where dbus just isn't reliably available, if at all, like Android, Blackberry, 
and iOS.

> I'm no expert in portability so you might have a point here when it
> comes to Windows but AFAIK there is no native APIs on Windows that you
> can use for this (maybe on Windows 8?) so I'd recommend working on
> geoclue with me to make it work on all platforms of interest rather
> than creating an abstraction layer on your end.
> 
> That would have actually been one opportunity to work together on
> this. The only reason we are keeping geoclue on freedesktop.org is
> that we are hoping for some contributions/collaborations from/with
> other DEs, especially KDE.

We have two reasons for doing things this way, one is so it's easy to write 
plugins for new platforms (including Android, Blackberry, iOS, etc) that use 
the host facilities.  On a platform without its own facilities like Windows we 
would still use the Geoclue plugin if it and dbus are available.

The second reason is independence from the backend system which may be on a 
different release cycle to KDE or have different api compatibility guarantees 
than we require, or may even become unmaintained or no longer meet our needs.  
Instead we offer our apps the api compatibility guarantee on our abstraction 
layer.  This allows the backend api or system to change without all our apps 
having to change, we only have to change our library or write a new plugin.  
For instance, we have a multimedia abstraction api that insulated us from the 
api breakages between gstreamer 0.8 and 0.10 and 1.0, and a hardware 
abstraction api that insulated us from the changes between hal and udisks.  

In short by using QtLocation / QtPositioning it allows our apps to use the one 
Qt-style C++ api throughout a major KDE release cycle and not worry if the 
host system is Geoclue 1 or Geoclue 2 or OSX or  Android or whatever, 
everything just works for them.

That's not to say apps can't use Geoclue directly for more advanced use cases 
than the abstraction api may provide, we try to follow an 80/20 rule for such 
things, most apps only have simple requirements which are met by the 
abstraction layer, those apps with the more complex requires will have the 
expertise and motivation to maintain their own cross-platform code for their 
use-case (e.g. Marble).

Certainly don't take this as our not being interested in working with Geoclue, 
our primary platform is Linux, and Geoclue is recognised as the de-facto 
platform api on Linux, so it's very desirable for us to ensure that Geoclue 
provides all the features we need, and has a sustainable future.  I do follow 
the Geoclue mailing list and wish I had time to contribute, but I have other 
priorities right now.  Hopefully this email will pique someone's interest to 
get involved, working on a new Geoclue 2 plugin for QtLocation would be a good 
introduction.

Cheers!

John.


>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
[prev in list] [next in list] [prev in thread] [next in thread]