On Sat, 2011-04-23 at 21:40 +0100, John Layt wrote: > On Thursday 21 Apr 2011 22:05:48 Bastien Nocera wrote: > > The current code uses json-glib, libsoup, and gvfs (for HTTP), though I > > can remove the gvfs requirement if MeeGo/KDE people are interested in > > the code. > > It is possibly something KDE could be interested in, although Bastien might > be > in a better position to comment on that.
If there's a Bastien other than me in this discussion, I'd be very very surprised :) > As a general word of advice from experience, if you want even the possibility > of other projects using a library you write then you need to make it as > generic as possible right from the start and with a clear design separating > the core and platform-specific parts. Even temporary solutions as a quick > hack using familiar technology have a bad habit of hanging around long after > they were intended (i.e. GeoClue and gconf :-). > > Just on the whole KDE situation, we've been looking into gelocation again and > this has led to one of our devs trying to work up a patch to remove the gconf > and gsettings dependencies. The patch proposal should turn up in the next > couple of weeks for discussion. The GConf dependency is already gone. And I wouldn't take a patch to remove the GSettings dependency. There's Qt bindings to access GSettings, and GSettings lives in GIO, which is also where the dbus-glib replacement (GDBus) lives. I don't think that trying to replace a library that's already in the dependencies due to the way packages are built is buying us anything but too moving parts. > P.S. Oh, and Quikee: that probably means no Vala, sorry. As much as I don't like Vala for its API instability, it's not a run-time dependency, it's a compile-time dependency for people compiling from git (eg. you'd ship the pre-processed C files in tarballs). _______________________________________________ GeoClue mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/geoclue
