An analysis about a generic desktop application configuration management system

[Waldo Bastian]

On Tuesday 12 April 2005 00:49, Philip Van Hoof wrote:
> And if you are really against the usage of Glib/GObjects then please
> feel free to talk about the alternatives on the wiki. The reason for
> GObjects is currently because it would be nice to "generate" the
> programming language bindings. At this moment it's very easy to create a
> language binding for a GObject oriented library: For most languages it
> can easily be generated (gtk-sharp is a nice example). Whats the
> alternative? I honestly don't know: I'm not an experienced KDE
> developer. You are one.
>
> Or are bindings for the different programming languages unimportant? I
> would disagree with such a statement. I'm not going to be the only one.

I think language bindings only play a role at the client side, and there KDE 
will want to offer a KConfig compatible API to KDE applications, and perhaps 
hook it into QSettings for Qt only applications. I expect that Gnome will 
want to offer something GConf/GObject oriented. I don't see a need for 
sharing the client side api. KDE/Qt already provides a wide variety of 
language bindings, so your favourite language binding will automatically get 
access to DConf settings when KConfig/QSettings start to provide that access.

I will make an architectural overview to illustrate what I mean.

Anyway, in my view the shared part will mostly be limited to the daemon side, 
keeping that part free of glib dependencies will certainly help to make it 
more acceptable for KDE. Depending on the amount of processing required at 
the client side there could perhaps be a small shared part at the client side 
as well, the same would apply there then.

Cheers,
Waldo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/xdg/attachments/20050412/5df9a7b1/attachment.pgp