An analysis about a generic desktop application configuration management system
rich at xmelegance.org
Tue Apr 12 01:39:38 EEST 2005
On Mon, Apr 11, 2005 at 06:35:39PM -0400, Avery Pennarun wrote:
> On Mon, Apr 11, 2005 at 11:23:42PM +0100, Richard Moore wrote:
> > I agree notifications and network transparency would be nice. Certainly
> > for the former, adding support to KConfig would be easier than any change
> > of the underlying implementation.
> Actually, I've personally ripped out and replaced all of KConfig's
> implementation to make it talk to UniConf instead, so I know quite a bit
> about how KConfig works. (I don't know much about KConfigXT, but it seems
> separate from this question.)
Neat, did you try doing it as plugin backend?
> I can say I'm pretty sure KConfig will mostly need to be redesigned - on the
> inside, not the API - in order to implement cross-process notifications.
> The problem is that to get cross-process notifications, you'll either need a
> FAM-like thingy, a daemon, or at least broadcasts over something like DCOP.
> All of these are major implementation changes that add up to about as many
> lines of code as KConfig already has.
I'm not sure you actually need cross-process, surely simply listing the
config files you're interested in is enough?
> If you're going to rip the guts out and replace them anyway, you might as
> well replace them with an implementation that someone else already wrote and
> tested carefully.
> Of course the API would also need to be slightly extended to allow you to
> register for notifications, but that would be backwards-compatible (you
> don't *have* to register if you don't care) and easy, so it's okay.
That could easily be added as a factory method that returns a QObject.
More information about the xdg