An analysis about a generic desktop application configuration management system
bastian at kde.org
Tue Apr 12 13:56:38 EEST 2005
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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/xdg/attachments/20050412/5df9a7b1/attachment.pgp
More information about the xdg