Category Archives: KDE

KSyntaxHighlighting – A new Syntax Highlighting Framework

Today, KDE Frameworks 5.28 was released with the brand new KSyntaxHighlighting framework. The announcement says:

New framework: syntax-highlighting
Syntax highlighting engine for Kate syntax definitions

This is a stand-alone implementation of the Kate syntax highlighting engine. It’s meant as a building block for text editors as well as for simple highlighted text rendering (e.g. as HTML), supporting both integration with a custom editor as well as a ready-to-use QSyntaxHighlighter sub-class.

This year, on March 31st, KDE’s advanced text editor Kate had its 15th birthday. 15 years are a long time in the software world, and during this time Kate won the hearts of many users and developers. As text editing component, Kate uses the KTextEditor framework, which is used also by applications such as KDevelop or Kile.

The KTextEditor framework essentially is an embeddable text editing component. It ships everything from painting the line numbers, the background color, the text lines with syntax highlighting, the blinking cursor to code completion and many more features. One major feature is its very powerful syntax highlighting engine, enabling us to properly highlight around 275 languages.

Each syntax highlighting is defined in terms of an xml file (many examples), as described in Kate’s documentation. These xml files are read by KTextEditor and the context based highlighting rules in these files are then used to highlight the file contents.

For the last 15 years, this syntax highlighting engine was tightly coupled with the rest of the KTextEditor code. As such, it was not possible to simply reuse the highlighting engine in other projects without using KTextEditor. This lead to the unfortunate situation, where e.g. the Qt Creator developers partly reimplemented Kate’s syntax highlighting engine in order to support other languages next to C/C++.

This changed as of today: The KSyntaxHighlighting framework is a tier 1 functional framework that solely depends on Qt (no dependency on Qt Widgets or QML), is very well unit tested, and licensed under the LGPLv2+. As mentioned in the announcement and in the API documentation, it is a stand-alone implementation of the Kate syntax highlighting engine. It’s meant as a building block for text editors as well as for simple highlighted text rendering (e.g. as HTML), supporting both integration with a custom editor as well as a ready-to-use QSyntaxHighlighter sub-class. This also implies that you can reuse this framework to add syntax highlighting to e.g. QML applications.

We hope that other applications such as Qt Creator will start to use the KSyntaxHighlighting framework, since it allows us to cleanly share one single implementation of the syntax highlighting engine.

In the next KDE Frameworks releases, we will remove KTextEditors syntax highlighting engine in favor of just using KSyntaxHighlighting. This will happen step by step. For instance, we already have a pending patch that removes all xml files from KTextEditor.git in favor of using the ones shipped by the KSyntaxHighlighting framework. That means, with the KDE Frameworks 5.29 release, Kate’s and KTextEditors dependency (and other application’s dependencies) will look as follows:

KTextEditor and KSyntaxHighlighting

This is quite an interesting change, especially since moving the syntax highlighting engine out of KTextEditor was already planned since Akademy 2013 in Bilbao:

Another idea was raised at this year’s Akademy in Bilbao: Split Kate Part’s highlighting into a separate library. This way, other applications could use the Kate Part’s highlighting system. Think of a command line tool to create highlighted html pages, or a syntax highlighter for QTextEdits. The highlighting engine right now is mostly internal to Kate Part, so such a split could happen also later after the initial release of KTextEditor on 5.

This goal is now reached – thanks to Volker Krause who did most of the work. Pretty cool!

If you are interested in using the KSyntaxHighlighting framework, feel free to contact us on our mailing list. Further, we welcome all contributions, so please send patches to our mailing list, or post them on phabricator. (You can also find the KSyntaxHighlighting framework on github for convenience, but it’s not our primary platform).

You can also support Kate and the KDE Frameworks by donating to the KDE e.V., KDE’s non-profit organization.

Bug Triaging Guest Blog: The wandering bug triager was here

I was contacted by Buovjaga from the LibreOffice QA team to spread the word about the current bug triaging efforts going on.

Therefore now a short guest block about that ;=)

Thanks to Buovjaga for trying to get some public interest in this important aspect of open source work: handling our flood of bugs!

<snip>

Free software needs more contributors from the non-coding user community. The problem is that there is no scientifically proven method for attracting them.

After dealing with thousands of LibreOffice bug reports and simultaneously trying to recruit more testers through various cunning plans, I realized the topic of free software quality assurance needs to become more prominent. I came up with the idea for a publicity stunt where I camp out at different bug trackers while telling the world about it. I chose KDE and Kate for my first month of triaging.

Bug triagers act as guardians of the bug tracker and save the developers from a lot of wasted time. If the number of unconfirmed reports in a project is not close to zero, it needs more triagers.

There were about 120 reports I deemed suitable for testing. I skipped crash debugging, testing of advanced features and only focused on the basic stuff. My take on the stats is that there is currently no one doing this sort of thing regularly for Kate.

To get started in triaging KDE bugs, you

– start testing unconfirmed reports and ancient confirmed ones while keeping the Bug triage guide at hand https://community.kde.org/Bugsquad/Guide_To_BugTriaging

– join #kde-bugs IRC channel after having commented on a bunch of reports and request rights to edit report details

– join the IRC channels of the products you are helping and coordinate testing with others https://userbase.kde.org/IRC_Channels#Applications

I believe a goal should be set for recruiting one person to deal with triaging per every actively-developed KDE product. After achieving this goal, it will quickly become apparent to each product team just how many triagers are needed in order for the work to be sustainable. However, the teams should not remain in isolation. The whole of KDE needs to become transparent. An “Everything about KDE” web dashboard would enable contributors to quickly see, which teams are in need of assistance. Tools for this are available in the Grimoire Lab suite http://grimoirelab.github.io/. KDE sysadmin team does not have the resources to set them up, so if you have the necessary skills and want to make this happen, please contact them on the #kde-sysadmin IRC channel.

If you want to contact me, you can find me on the #libreoffice-qa channel @ Freenode network, nickname: buovjaga.

</snip>