On Wednesday, 2010-11-03, Aaron J. Seigo wrote: > On Wednesday, November 3, 2010, Kevin Krammer wrote: > > On Wednesday, 2010-11-03, John Layt wrote: > > > The obvious backend solution is Geoclue, a freedesktop.org project > > > which is available on almost all distro's now, is used by Gnome, and > > > is an official part of the Meego platform. The problem comes in the > > > api to access Geoclue, which is a DBus based service with C bindings, > > > as we would obviously prefer a Qt-ish C++ wrapper for convenience. > > > > What kind of problem do you have in mind regarding a service with a D-Bus > > API? There are already tons of these and they are using D-Bus as the > > primary API exactly because it allows developers on different technology > > stacks to use their preferred way of handling the protocol. > > a) annoyance of using DBus directly
It's a single line in the CMakeLists.txt, isn't it? > b) changes in the DBus API are out of our control. Sure, but upstream API changes are always out of our control. Anyway, neither of these would impose a problem of having a Qt style API for the service. > 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? This sounds weird. I have to admit I don't know anything about the Geoclue architecture, but how would a service implementation detail become a client dependency? Do the D-Bus calls transport GConf keys? Cheers, Kevin -- Kevin Krammer, KDE developer, xdg-utils developer KDE user support, developer mentoring
signature.asc
Description: This is a digitally signed message part.
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
