For 25 years, the KDE community has been using Qt to develop various free software products. These include the Plasma desktop environment, creative tools like Krita and Kdenlive, educational apps like GCompris, groupware suites like Kontact, and countless other apps, utilities, and widgets.
Qt is known for its rich high-quality cross-platform API. However, it does not cover every use case. In fact, this is impossible. So, to fill the gaps, KDE created code that has been merged into many KDE projects over time. To facilitate reuse of these battle-tested solutions outside of KDE projects, KDE shares this code in the form of modular libraries.
We call these libraries KDE frameworks .
Currently, there are 83 KDE frameworks that provide a wide range of functionality. For example, KNotifications allows you to create popup notifications on Windows, macOS, Linux, and Android without writing platform-specific code. Other frameworks provide wrappers around specialized libraries or interfaces, making them easier for Qt programmers to use. For example, the bluez-qt framework provides a Qt-style interface to the bluez D-Bus API. Some frameworks are collections of useful classes, such as KWidgetsAddons, which contains many useful widgets that are not part of QtWidgets.
As a Qt developer, you may have unknowingly used software built with the KDE framework. The syntax highlighting framework that powers KDE applications such as Kate and KDevelop is also used in Qt Creator.
There are many benefits to utilizing the KDE framework. In this series, we'll examine some of them, providing practical and real-world examples to help you learn how to integrate the KDE framework into your own products.
In the first blog in this series, I want to introduce you to KConfig.
KConfig is one of the most used frameworks. It allows developers to store and retrieve configuration data in the file system. Its basic functionality is similar to Qt's own QSettings, but it provides some additional functionality.
Before we can use KConfig in our application, we need to add it to our build system. For CMake, this is done as follows:
If your application uses QMake, you only need to:
The following code shows the basic usage of KConfig:
First, create a KConfig object. By default, the configuration is saved in a file with the name specified in QStandardPaths::GenericConfigLocation, but the exact location can be adjusted.
Configuration entries are organized into groups. Each KConfig object can contain multiple groups, and each group contains multiple key-value pairs containing configuration data.
To read configuration entries, first create a KConfigGroup from a KConfig object, then use readEntry to query for a specific key. readEntry takes an optional default value, which will be used when no data is stored for that key.
To write settings, use writeEntry. Data is not written to disk immediately. When the KConfigGroup object is destructed, all pending write operations will be performed. Writing to disk can be forced using the sync() method.
So far, all of this is possible through QSettings. So, what are the benefits of using KConfig?
Both QSettings and KConfig allow configuration cascading. Here, configuration values are read from two locations: system-wide configuration values and a per-user location. This allows system-wide defaults to be defined and enables users to override their values. However, in an enterprise setting this may not be desirable. KConfig allows system administrators to mark settings as immutable, preventing users from overriding provided defaults. This does not require any code changes in the application. Applications can query whether a key is marked immutable to disable the associated UI part.
Sometimes two processes access the same configuration file. Here it is important to notify one process when another process changes the configuration so that it can react accordingly. KConfigWatcher allows to notify another process about configuration changes. It does this via D-Bus. Therefore, it only works on systems where D-Bus is available (i.e. Linux).
This simple usage of KConfig (and QSettings) has many disadvantages. The library/compiler has no information about configuration data structures. Most access is done using string identifiers. These are prone to typing errors, which the compiler cannot verify at build time. There is also no information about the data type of the configuration entry, for example, whether the entry is a single string, a list of strings, or an integer. Another problem is that KConfig cannot be used directly in a QML context.
KConfig provides the KConfigXT mechanism to solve these two problems. It is based on an XML description of the configuration data structure. At compile time, this information is used to generate the C++ classes used to access the configuration. This class can also expose the entry as a property so that it can be used directly by QML.
The above example expressed as an XML description looks like this:
This is stored in the myappsettings.kcfg file.
The behavior of KConfigXT is controlled by a separate configuration file myappsettings.kcfgc:
Then the above code example becomes:
