Tag Archives: planet

Tracking KDE Development

A central place to track KDE development is the kde-commits@kde.org mailing list. To this mailing list, all code changes are sent, containing the log message as well as the diff that quickly shows what really changed. In the early days of KDE development, the changes were maintained by the CVS version control system. Later, this was changed to subversion. Nowadays, KDE mostly uses git, but some svn modules are still around.

Since KDE is developed by many contributors, the  kde-commits@kde.org mailing list obviously has high traffic, ranging from ~100 mails up to 400 mails a day (see marc.info for statistics).

Many developers are subscribed to this mailing list. However, due to high traffic and possibly many changes that are unrelated to your pet project, a commit filter was invented, which was available on https://commitfilter.kde.org for a long time. Essentially, this commit filter allowed to easily setup filters in terms of regular expressions, such that you’d only get mails for changes you are interested in. While this was convenient, the commit filter also had its drawbacks: Instead of getting all KDE changes, you missed a lot possibly interesting conversations: Since post-code reviews are often done by others through email conversation directly on the code changes.

Nowadays, the commit filter is not available anymore, mostly for security reasons since it was unmaintained for a long time.

What does that mean? I’m subscribed to kde-commits@kde.org again, getting all changes. In fact, I am enjoying skimming quickly through the changes, even doing a code review here and there.

I recommend every KDE contributor to subscribe to this mailing list, since it is very interesting to see which projects are actively developed and who really contributes to KDE in person. Even better, sometimes there are discussions on this list, helping you to learn things you didn’t know. Of course, nowadays we also have many code reviews on phabricator, but still the commit mailing list is a nice addon to track KDE development.

Syntax Highlighting Checker

The KTextEditor Framework uses the syntax highlighting files provided by the KSyntaxHighlighting Framework since the  KDE Frameworks release 5.28.

The KSyntaxHighlighting Framework implements Kate’s highlighting system and meanwhile is used in quite some applications (e.g. LabPlot, KDE PIM). What is quite nice is that the KSyntaxHighlighting framework is nicely unit tested. And while we do not have tests for all highlighting files, we still provide some quality assurance through a compile time checker.

How does it work? Well – in former times, Kate loaded all highlighting .xml files from disk (through the KTextEditor framework). This lead to a slow startup over time, since there are >250 .xml files that needed a stat system call at startup.

With the KSyntaxHighlighting Framework, all these xml files are compiled into a Qt resource (qrc file), that then is included into the KSyntaxHighlighting library.

In order to create the Qt resource file, we need to iterate over all available xml files anyways. So what happens is that we take this opportunity and also scan the highlighting files for common mistakes.

As of today, we are checking the following:

  1. RegExpr: A warning is raised, if a regular expression has syntax errors.
  2. DetectChars: A warning is raised, if the char=”x” attribute contains more or less than one character, e.g. when char=”xyz”, or char=”\\” (no escaping required), or similar.
  3. Detect2Chars: Same as DetectChars, just for char=”x” and char1=”y”.
  4. Keyword lists: A warning is raised, if a keyword entry contains leading or trailing spaces. Additional trimming just takes time.
  5. Keyword lists: A warning is raised if a keyword list is unused.
  6. Keyword lists: A warning is raised if multiple keyword lists use the same me (=identifier).
  7. Keyword lists: A warning is raised if a non-existing keyword list is used.
  8. Contexts: A warning is raised, if a non-existing context is referenced.
  9. Contexts: A warning is raised, if a context is unused.
  10. Contexts: A warning is raised, if multiple contexts have the same name (identifier clash).
  11. Attributes: A warning is raised, if non-existing itemData is used.
  12. Attributes: A warning is raised, if multiple itemDatas use the same name (identifier clash).
  13. Attributes: A warning is raised, if an itemData is unused.

This list helps us nicely to catch many mistakes at compile time even before running unit tests.

Update (2017-12-17): All above issues are fixed for all highlighting files starting with the KSyntaxHighlighting 5.42 framework, to be released in January 2018.

KTextEditor depends on KSyntaxHighlighting

Recently, the KSyntaxHighlighting framework was added to the KDE Frameworks 5.29 release. And starting with KDE Frameworks 5.29, KTextEditor depends on KSyntaxHighlighting. This also means that KTextEditor now queries KSyntaxHighlighting for available xml highlighting files. As such, the location for syntax highlighting files changed from $HOME/.local/share/katepart5/syntax to


So if you want to add your own syntax highlighting files to Kate/KDevelop, then you have to use the new location.

By the way, in former times, all syntax highlighting files were located somewhere in /usr/share/. However, since some time, there are no xml highlighting files anymore, since all xml files are compiled into the KSyntaxHighlighting library by default. This leads to much faster startup times for KTextEditor-based applications.

Running Unit Tests

If you build Kate (or KTextEditor, or KSyntaxHighlighting) from sources and run the unit tests (`make test`), then the location typically is /$HOME/.qttest/share/org.kde.syntax-highlighting/syntax.

FirstAid – PDF Help Viewer


in the recent months, I didn’t find much time to spend on Kate/KTextEditor development. But at least I was now able to spend a bit more time on OpenSource & Qt things even during work time in our company. Normally I am stuck there with low level binary or source analysis work.

For our products, we were in the need of some online help. As our documentation is delivered as PDFs generated by the tools of the TeX Live distro, a natural idea was to use some PDF viewer and integrate it more tightly in our software than just “open the manual at page 1”.

We did review PDF viewers out there, but most (like Okular) have too many dependencies to be just bundled with our product (or a license not permitting that).

Without bundling, we can’t ensure that the tight coupling is working, without starting to test the integration with X different viewers which more or less all need other kinds of command line arguments to open the right page or even lack that feature or will not reuse an already running instance, ….

Therefore, as our GUIs are developed with Qt anyways, we did take a look at libpoppler (and its Qt 5 bindings), which is the base of Okular, too.

Easy enough, taking the small demo program shipped with the library and adding a small stdin based interface to tell it “goto <named reference>” we arrived at some small PDF viewer that is fit enough for our use case.

We named the thing “FirstAid”, the sources can be grabbed at github.com/AbsInt/FirstAid. Like libpoppler and the demo, its licensed as GPLv2+.

As already the README states, the aim of this small project is not to replace some full fledged viewer like Okular, the design goal is to have a small viewer that is auto-started by some host application and will jump to the requested labels for a tightly coupled online help. It can be used as a pure standalone PDF viewer, too, but that is more intended for testing it e.g. on the documents that should later be shown as online help.


I already annoyed Albert with some small issue I had with libpoppler, perhaps I will provide more useful fixes in the future if more things come up during FirstAid development. In any case, already THANKS A LOT for the Qt 5 bindings around libpoppler, they work nicely for us!

I really think this small project shows the benefit of OpenSource: We needed a PDF viewer, we were able to create a small one in less than a month based on OpenSource libraries and we can give back the results to the community (if it is useful for others is a different story, but perhaps other people have the same itch to scratch, if not, ignore it). I hope more possibilities for such things come up at work in the future.

For building: It should build out of the box if you have some recent Qt and libpoppler-qt5-dev installed, at least the Travis CI is able to build it out of the box with the given config. For me, it shows some small bugs if used with Qt 5.6/7 compared to the Qt 5.8 Beta I used here for testing.