This re-licensing only covers the actual code in the library and the bundled themes but not all of the syntax highlighting definition data files.

One of the main motivation points was to get QtCreator to use this, if possible, instead of their own implementation of the Kate highlighting they needed to create in the past due to the incompatible licensing of KatePart at that time (and the impossibility to do a quick split/re-licensing of the parts in question).

We talked about that possibility on Akademy this year and it seems, that if time permits, this will be picked up by the QtCreator team.

The current state allows the use of this tier 1 framework by projects like Qt(Creator), that require non-copyleft licenses for bundled 3rd-party source components, but in addition also for commercial applications that do static linking against a commercial Qt version.

Whereas at the moment, the QtCreator integration has not yet started (at least I am not aware of any work for that), a first commercial consumer already exists.

The company AbsInt I work at does develop both binary and source level analysis tools. Our GUI is Qt based, statically linked with a commercial license.

Before the current release, our GUI used a handcrafted highlighter for our own annotation languages and the programming languages we support (e.g. C and C++). After the release of the 5.50 MIT licensed KSyntaxHighlighting, this was changed to use the framework through its QSyntaxHighlighter implementation.

The framework was easy to integrate into our static build process. To make it possible to be used without violating licensing for the bundled highlighting definitions that are not MIT and ensure no other installed instances of the framework will mess up the shipped highlighting definitions, the following two changes were contributed upstream.

A CMake switch to disable the bundling of the syntax definition data files into the library. This avoids mixing non-MIT files into the created static library, which then only contains MIT licensed code and data. One can then let people either download the definitions or ship some as extra data files with an extra licensing.

cmake -DQRC_SYNTAX=OFF

A CMake switch to disable the lookup for syntax and theme definitions in the normal locations via QStandardPaths. This allows the user of the library to only load definitions from search paths specified manually. No definitions that e.g. are installed by users for Kate or other applications using the framework will mess up your lookup, which is really important if you rely on exactly your files to be used.

cmake -DNO_STANDARD_PATHS=ON

These two options might be interesting for the QtCreator people, too. If they need additional configurability, I am sure we can find ways to integrate that.

After the transition, my colleagues compared the speed of the old implementation versus the new generic highlighting engine. At first, they were not that impressed, which did lead to several performance improvements to be implemented and up-streamed.

All directly visible bottle-necks got perf’d away. The most CPU consumption now more or less boils down to the costs of the used regular expressions via QRegularExpression. Same for the allocations, we reduced them by taking a look on the heaptrack profiles for the KSyntaxHighlighting benchmark suite.

But as always, performance work is never done, if you have time, you can take a look by profiling the “highlighter_benchmark” autotest, that applies the shipped highlightings to the test files we have in the repository.

There is no divergence in the local git clone at AbsInt at the moment, nor is there any plan to have that in the future. Both sides profit from up-streaming the changes. Other consumers of the framework get improvements and AbsInt doesn’t need to maintain a patched version.

Starting with the 18.10 release of our tools, all highlighting is handled by the framework, no more error-prone handcrafting of QSyntaxHighlighter implementations.

Thanks to all people that helped making this possible ;=)

I hope more projects/companies will pick up the use of this pure qt-dependent tier 1 framework in the future and up-stream their improvements. Be welcome.

For quite some time, the KDE e.V. – KDE’s non-profit organization – is listed in the AmazonSmile program. On the AmazonSmile website it says:

AmazonSmile is a website operated by Amazon that lets customers enjoy the same wide selection of products, […]. The difference is that when customers shop on AmazonSmile (smile.amazon.com), the AmazonSmile Foundation will donate 0.5% of the price of eligible purchases to the charitable organizations selected by customers.

In other words, if you do a lot of shopping on Amazon anyways, make sure to start shopping via smile.amazon.de and choose the “KDE e.V.” as organization. This way you financially support the KDE e.V., even without having to pay more. I am posting this here since I know many people who buy things on Amazon several times a week. Feel free to spread the word & happy shopping 🙂

PS: This is not supposed to be advertisement for Amazon. You can also donate to the KDE e.V. directly.

Just as quick info: For some time, there is a sticky thread on r/cpp about who is hiring C++ developers. This thread gets cleaned quarterly, so all the open jobs listed there are likely still open. The same was just started on reddit for r/Qt5: Who’s Hiring Qt Devs – Q4 2018: So if you are looking for either C++ or Qt jobs, this is a good place to have a look at from time to time. When I just looked for r/Qt5, the list was still empty, but this hopefully changes soon, given that the post was added just some hours ago. 🙂

During Akademy I once more was a bit disappointed how bad the project plugin of Kate can cope with out-of-source builds.

At work, we use in-source-builds, as we normally only build in one configuration and have no issues with left-overs in the source directories locally. For this use-case, the project plugin works really well. You have your project local terminal view and that allows you all normal things you need during work, e.g. building + using the git command line client for the version control work.

On the other side, with out-of-source builds, that no longer is that nice to use. Either you use the .kateproject generated by the “Kate – Ninja” or “Kate – Unix Makefiles” CMake generators, then your terminal defaults to the build directory, which allows building just fine, but no version control stuff, or you use the .kateproject (or auto-project creation) in the source directory, which doesn’t allow you to build nicely inside the terminal prompt of Kate. There are workaround for that, like having shell magic to switch between source and build directory with ease, but that all feels a bit unnatural.

Therefore, I added today a very simple “fix” for the issue: If you have a .kateproject that has a different base directory (the toplevel “directory” entry) than the directory the .kateproject file is located in, you will get two terminal tabs in the project view. One is the “old one” that has the directory of the .kateproject as base, the other has the base directory of the project as base.

With these two views, you can easily switch between build/source directory without any hassle or extra setup for any properly setup .kateproject as generated by CMake.

I hope this improves the usability of the project plugin for the normal setup of out-of-source builds with CMake. If this sparked your interest: any further improvement ideas are welcome, best as patches submitted on phabricator.kde.org.

I think this small change is something that shows how many open source contributions work: You have some itch to scratch and you share your solution to help others that have a similar issue.

If you look at the open bugs & wishes for Kate/KWrite/KTexteditor/… you will see that there are still a lot things that need some scratching. It might look like the developers don’t care for the issues of their users, but that is not correct. We just don’t have the time to scratch all these itches (nor are all that easy solvable). Sometimes we unfortunately did even lack time or motivation to do proper reviews for some proposed solutions, I hope we improve on that in the future. Any volunteers that help us taking care are always welcome. The addition of the inline notes interface is a nice example. Michal Srb provided an initial solution for his own needs to us and sparked some new development with that.