Camp KDE: Geolocation [LWN.net]

Camp KDE: Geolocation

Posted Apr 6, 2011 20:48 UTC (Wed) by JohnLenz (guest, #42089)
Parent article: Camp KDE: Geolocation

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.

Camp KDE: Geolocation

Posted Apr 6, 2011 22:17 UTC (Wed) by jstaniek (guest, #72333) [Link] (2 responses)

"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

Posted Apr 6, 2011 22:42 UTC (Wed) by JohnLenz (guest, #42089) [Link]

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

Posted Apr 17, 2011 9:03 UTC (Sun) by krake (guest, #55996) [Link]

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.