LWN: Comments on "Camp KDE: Geolocation"

Camp KDE: Geolocation

krake — Sun, 17 Apr 2011 09:03:27 +0000

But the backend has to be configured, as you said. And if this configuration system is not a standard, then the whoe solution is not a standard.

I don't agree. The only thing you need to have fixed and neutral is the D-Bus API of the service.

As a client you don't care about any choice in the service's implementation. You simply run the service's D-Bus XML introspection file through qdbusxml2cpp and are done.

The service's D-Bus API would have to be serioulsy flawed to require any kind of dependency to be also present on the client side.

GConf dependency? (was Camp KDE: Geolocation)

krake — Sun, 17 Apr 2011 08:57:49 +0000

Actually I never understood this "problem". When asking on a KDE mailinglist where this was discussed I didn't even get a reply.

gconf, GSettings or whether is a service side dependency right?
How would any client be affected by the service's choice of dependencies?

Same for the dbus-glib dependency, any client will use whatever D-Bus implementation they are usually using.

Camp KDE: Geolocation

ssam — Fri, 08 Apr 2011 11:49:52 +0000

another source of location data is cell phone towers (assuming you have a device that can see these). There is an open database of these http://realtimeblog.free.fr/ that could be used.

compared to GPS it has almost instant fix (GPS will usually take 30-60 seconds, but can be much longer from cold), highest resolution in cities (more towers) where GPS can have trouble due to less visible sky. however it is lower resolution, and needs a database or network connection. it can be used to seed a GPS for a quicker fix.

Camp KDE: Geolocation

iksaif — Thu, 07 Apr 2011 05:58:45 +0000

QtLocation already have support for Google Maps, Open Street Maps and Open Cycle Maps. And plugins are really easy to write.

See:
http://qt.gitorious.org/~dalaing/qt-mobility/meego-maps-q...
http://xf.iksaif.net/dev/qtm-geoservices-extras.html

But currently QtLocation map widget is unusable on Symbian and Maemo because of huge number of bugs, and the best solution for these platforms is QMapControl.

GConf dependency? (was Camp KDE: Geolocation)

hadess — Wed, 06 Apr 2011 22:44:45 +0000

> GeoClue is also attractive if the gconf dependency can be removed

I wish people checked code before making assumptions. It now uses GSettings, and has for the last 4 weeks or so. The patch was available for nearly a year.

Qt has had GSettings bindings done, as sponsored by Canonical.

The only non-glib (as in, a dependency not in the glib tarball) is dbus-glib, and I believe that we'll work on removing the dependency as time goes on (to be replaced by GDBus).

Camp KDE: Geolocation

JohnLenz — Wed, 06 Apr 2011 22:42:34 +0000

With the caveat that I have never heard of the geoclue project before today, a quick glance at the source code shows that geoclue did abstract the settings choice.

The only place I can find using gsettings in geoclue is about 100 lines of code in main.c which loads settings into a hashtable. It should be easy to change that to a file in /etc or ksettings or whatever.

Camp KDE: Geolocation

jstaniek — Wed, 06 Apr 2011 22:17:08 +0000

"If freedesktop standardizes a dbus api for geolocation, then kde apps and gnome apps can interoperate without caring what the backend is."

But the backend has to be configured, as you said. And if this configuration system is not a standard, then the whoe solution is not a standard. Imagine having dependency on KConfig in GNOME or gconf (or dconf) in KDE. Portable things does not work this way, so geoclue should have abstracted configuration system to be widely usable.

Camp KDE: Geolocation

vmj — Wed, 06 Apr 2011 21:26:03 +0000

That reminds me of freesmartphone.org project. They are trying to define DBUS APIs for location services, among other things.

I haven't been paying attention to their progress, though.

Camp KDE: Geolocation

JohnLenz — Wed, 06 Apr 2011 20:48:20 +0000

My first thought is why use a library for geolocation?

Geolocation data should be accessed through dbus, so that the user only needs to configure the source (or list of sources) once in a dbus server, and all apps can query the location without having to worry about settings and all that.

If freedesktop standardizes a dbus api for geolocation, then kde apps and gnome apps can interoperate without caring what the backend is.