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 on KDE PIM) 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 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 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.