KDE Geolocation Services

John Layt johnlayt at googlemail.com
Thu Nov 4 15:04:33 GMT 2010

On Thursday 04 November 2010 14:43:19 Kevin Krammer wrote:

> Ah, you meant using the D-Bus API directly in apps. I interpreted it as in
> not using their C library, i.e. using D-Bus indirectly (through their C
> wrapper).


Yes, just to be clear, our api would only call their DBus interface, we would 
not use their C api and all the G stuff that would make us depend on directly.  
No hard compile or runtime dependencies at all, in fact.

Which kind-of makes the whole GConf usage moot?

> > > Do the D-Bus calls transport GConf keys?
> > 
> > No, I understand it uses it for storing some internal config for the
> > Master Provider, there's no GConf stuff in the dbus calls.  In fact, I
> > think it even provides a dbus api for changing the Provider config
> > (which are not in GConf) which that Master Provider also responds to. 
> > So we wouldn't have to deal with GConf at all, it's just an
> > implementation detail at their end, but also an added dependency we may
> > not want, but is entirely optional is we're willing to write our own
> > Master Provider.
> I don't think that a service's dependencies are of any concern to us.

In theory, no concern to us, but we do need to consider what happens if a user 
refuses to install the Master Provider due to GConf, or Geoclue at all due to 
Glib/GObject.  A nice default is always good.  No Master Provider, fall back 
to a simple guess on what Provider will work best.  No Geoclue, try another 
bankend, or fall back to a simple hostip implementation, or just return their 
preset home location.

>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

More information about the kde-core-devel mailing list