AW: KNewStuff for KateSchemes?

dhaumann at dhaumann at
Mon Sep 26 17:39:12 UTC 2016

‎Btw, Volker initiated a new SyntaxHighlighting git repo, which reimplements the entire syntax highlighting engine.

In addition, it ships a html highlighter and a QSyntaxHighlighter (also usable in QML).

We extended this the last weeks to include Color Themes. There, a Theme is self-contained. 

You can find more details here:

And here:

‎The idea indeed is to have a library that does the highlighting and is nicely reusable.

The first frameworks release is planned for next Saturday, we'll see when we can meet this goal.

Comments, patches and reviews welcome :)


Von: Dominik Haumann
Gesendet: Mittwoch, 18. Mai 2016 18:35
An: Alexander Zhigalin
Cc: kdevelop-devel; kwrite-devel
Betreff: Re: KNewStuff for KateSchemes?

Hi Alex,

you are missing the body of the mail. A mail without contents is
typically not how we communicate.

With respect to the topic: Yes, KNewStuff for schemas would be nice,
but I would like to first discuss whether we shouldn't change the
format of the exported schemas, and in general hour our hl schemas

The format right now sucks:
1. Parts of the scheme are in kateschemarc.
2. other parts are in katesyntaxhighlightingrc
3. katesyntaxhighlightingrc looks like this:
Base-N Integer=ffb08000,ffffdd00,,,,,-,-,,---

In my opinion, this is not readable, therefore hard to maintain. And
also the split in two files is the reason why we cannot simply ship
one file that contains all colors.

Instead, what I propose:
- save each schema in one file.

Then we'd have:
- one Normal.kateschema
- one Printing.kateschema
- one Breeze Dark.kateschema
- ... etc

and in addition to that, I suggest that shipped schemas from us are
read-only. If one wants to edit a schema one simply copies it (needs a
button in the UI, like qt creator). This has the advantage, that if we
ship updated ones, the user's schemas are not overwritten.

And I suggest that we choose either xml (like for our syntax
highlighting) or JSON as format.

When we have that, *then* I think KNewStuff is a good idea.


More information about the KDevelop-devel mailing list