Developers 

With the KDE Frameworks 5.50 release, the KSyntaxHighlighting framework was re-licensed to the MIT license.

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).

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.

Thanks to Michal Srb and Sven Brauch for pioneering the work an a new KTextEditor interface that allows applications like Kate, KDevelop, etc. to display inline notes in a text document. As demo, we quickly prototyped one application to display colors in CSS documents:

Clicking on the color rectangle will launch the color chooser:

The Akademy 2018 ends today.

Like each Akademy I attended, it was an interesting experience. As the location switches around each year, so does the set of people attending change every year, too.

That is actually nice, as you get always to meet some of your old “friends” but additionally new members of the KDE community. I think this kind of “conferences” or “meetings” are an important way to get some more cohesion in the community, which is sometimes a bit lacking between people only meeting online via mail/…

During Akademy there was finally enough time to finalize the porting of KTextEditor to KSyntaxHighlighting.

Thanks to the help of Dominik and Volker, the needed extensions to the KSyntaxHighlighting framework were done in no time ;=)

Thanks for that!

The branch for the integration was merged to master yesterday, unit tests look OK and I am using that state now for my normal coding work. Beside minor glitches that should now be corrected, no issues came up until now.

After fixing some first porting bugs to KSyntaxHighlighting, code folding (non-indentation based) is back working, too.

There is a still a lot to do (and e.g. the syntax colors are still kind of randomized), but already all KTextEditor original highlighting code is gone without ending up in an unusable state.

After several years, the time has come that KTextEditor finally starts to use more of KSyntaxHighlighting than just the syntax definitions resources.

At the moment, we still do everything on our own (parsing the xml, doing the highlighting, …) and only use the XML files bundled inside the KSyntaxHighlighting library as “code sharing”.

I started a “syntax-highlighting” branch in ktexteditor.git to change that. Dominik helped out by starting to add missing API to KSyntaxHighlighting that will ease the porting.

When building the KSyntaxHighlighting framework, the syntax highlighting xml files are compiled into the KSyntaxHighlighting library. In order to do so, we have a small little helper program that generates an index of all xml files. This indexer also validates the xml files against the XML Schema, and performs some more sanity checks.

Review request D10621 tries to extend the indexer even further and suggest optimizations for our highlighting files. For instance, the rule