[dot] Cornelius Schumacher on KConfig XT

[Dot Stories]

URL: http://dot.kde.org/1120775836/

From: Jonathan Riddell <>
Dept: but-what-does-xt-stand-for
Date: Thursday 07/Jul/2005, @17:37

Cornelius Schumacher on KConfig XT
==================================

   KConfig XT is an increasingly commonly used technology in KDE
programmes.  KDE Dot News talked to creator Cornelius Schumacher (also
recently interviewed about KDE PIM [http://dot.kde.org/1117363968/]) to
find out the advantages of KConfig XT over plain old KConfig.  Read on
for the full interview -- and if you think your programme might benefit
from KConfig XT, Zack's tutorial
[http://developer.kde.org/documentation/tutorials/kconfigxt/kconfigxt.html]
is a good place to start.
  Cornelius
     Most developers will be familar with KConfig which reads and saves
settings out to files. What does KConfig XT add to this?

     While KConfig is a powerful and efficient way to handle
configuration settings it doesn't address two things: Type safety and
GUI. KConfig is great as backend, but to address these two areas we had
to put another layer on top of it. That's what KConfig XT is. The key
feature of KConfig XT is that it provides a machine-readable description
of the configuration settings, so that we can do all kind of fancy stuff
like generating type-safe code to access the settings, associate the
settings with a GUI or provide tools like Zack's KConfigEditor
[http://extragear.kde.org/apps/kconfigeditor/] with the ability to give
the user the needed context for editing configuration files.

     What do you mean by "type safety" in the context of KConfig XT?

     To access a setting by KConfig you need to know two things: the
string representing the key of the setting and the type of the setting.
If you make wrong assumptions about the type, KConfig can do nothing to
prevent this. It will happily read a string as a number, if requested by
the programmer. Another source of error are the string keys. If you make
a typo in the string KConfig once again can do nothing to prevent this.
Your program will behave strange with no indication of the error.

     KConfig XT solves these problems. It takes an XML description of
the configuration settings and automatically generates the code
necessary to access them. The generated code provides a clean type-safe
API and all the error-prone string key and type handling is
encapsulated, so that the developer doesn't have to care about this
anymore. So if the developer now makes errors when accessing the
settings, the compiler is able to tell, if the name of the setting or
the type are wrong.

     As an additional benefit the generated code also takes care of
reading and writing the settings, immutable settings, labels and
whatsthis texts, singleton access, default values and more.

     KConfig XT can generate configuration dialogues, how does it
achieve this?

     Right now KConfig XT can't fully automatically generate dialogs.
But it provides a very easy way to associate widgets from a dialog with
configuration settings. This makes it possible to create a dialog for
example with Qt Designer and just by associating the widgets via their
names with the settings get all the reading and writing of the setting
for free. So you can create a configuration dialog without writing any
C++ code.

     The next step would be to also generate the dialog from the
settings description. I'm quite sure that it's possible to do that for
at least 90% of the KDE configuration dialogs. Up to now there only is a
very small prototype, but I hope I can provide a more complete solution
by aKademy this year.

     Is using KConfig XT any easier for a programmer than directly
reading and writing using KConfig?

     Definitely. My main motivation when starting to write KConfig XT
was to get rid of the need to write all that annoying and error-prone
code to handle KConfig settings at the string key level, with all the
unnecessary duplication of things like default values. I think, this
mission was accomplished. Once you get used to KConfig XT you don't want
to go back anymore.

     The KConfig XT tutorial states that it makes the administration of
large KDE installations more manageable, how does it achieve this?

     KConfig XT provides a simple and machine-readable description of
the configuration settings. This can be used by management tools to
effectively handle configuration files without the danger of making
wrong assumptions about their content.

     What prompted your development of KConfig XT?

     As I already said, my main motivation was to get rid of the
annoyance of having to write the same ugly code for accessing
configuration settings again and again. One of the most central
principles of software design is the DRY principle: Don't Repeat
Yourself. I felt that having to deal with KConfig directly violated this
principle in numerous ways. KConfig XT is the solution to this problem.

     What problems did you come across when developing KConfig XT?

     The heart of KConfig XT is "kconfig_compiler", the tool which takes
the XML description of the settings and generates the C++ code to access
them. Writing code that writes code always is, well, interesting. You
have to think in a very twisted way, because of the additional
indirection. Especially when it comes to things like escaping
characters, it's easy to get lost. On the other hand it's fun, because
it's challenging and you can feel the power of this technique, because
you can have great effects with only very little code.

     Another challenge was the integration with the build system,
because using code generators, integrating the generated code in the
build system and getting the dependencies right doesn't work out of the
box. Fortunately our build system gurus did a great job and tackled this
problem. Now it's dead easy to use KConfig XT: Write the XML file, add
it to the sources line of your make file, enjoy the comfort of the
generated classes.

     Has there been much take up of KConfig XT in KDE?

     KConfig XT is used all over the place now. Not all applications
have been ported yet, but when reading the commit messages you will
notice "ported to KConfig XT" commit logs again and again.

     What is the best example of KConfig XT use in KDE?

     Good question. I don't have a complete overview about where it is
used and I actually can't imagine how it could be used in a bad way, as
the interface is pretty straight-forward. But I would recommend to look
at KOrganizer because that's where it all began.

     Sebas on IRC wonders if KConfig XT supports locking for Kiosk and
about the possibility of a network option for editing settings on a
remote machine.

     I don't think that's in the scope of KConfig XT. Locking is
probably more a backend issue and remote editing I would see on the
application level. As far as I know KConfigEditor already provides the
option of remote editing configuration files.

     There has been some discussion on freedesktop.org's XDG mailing
list about a possible cross-platform configuration system (DConf), how
would this affect KConfig XT?

     This probably wouldn't affect KConfig XT too much, at least not its
users. KConfig XT is an abstraction of the actual configuration system,
so it would be quite easy to make use of another backend. If the efforts
at freedesktop.org come up with a new unified configuration system, KDE
is certainly in a good position to make use of it. That's the power of
our framework.