KDE 3.2 will introduce an improved configuration framework, known as KConfig XT. This new framework extends, not deprecates, the current KDE configuration API. But if Gnome and KDE continue to have a different API for configuration, how easy freedesktop.org’s goal would be to uniform the backends of the two popular DEs? We spoke to freedesktop.org‘s founder, Havoc Pennington, and here is what he replied after having a quick look at the new KDE API: UPDATE: Read on for KDE/SuSE’s Waldo Bastian reply too:
Looking at it quickly –
I don’t think there’s a step backward here, as it’s really just a change
to the KDE APIs, not to the on-disk config system.
I would like to see motion toward a unified config system, but that is
probably aided by this change more than hindered, since the additional
abstraction the new KDE API offers would simplify using a different
It’s possible I don’t understand all the issues of course.
It’s pretty much a KDE internal thing to be used by KDE applications. At the moment configuration options for KDE applications are very much undocumented and you will need to dig through the source to find all possible options.
With KConfig XT there will be a machine readable representation of
configuration options. It also makes it a lot easier for us to link a certain
configuration option with it’s visual representation in a settings dialog,
allowing for more automation and less work for the developer.
I see little impact on Gnome/KDE uniformity. The machine readable descriptions may come in handy at some point in the future if we were to attempt to unify the backends for GConf/KConfig. That’s not something that has very high priority for me though, since the impact for interoperability is quite limited. Applications like gedit don’t tend to be very interested in the configuration of KEdit and vice versa. Only the desktop-wide settings (KDE’s kdeglobals config) are interesting in that context I think.