Category Archives: KDE

Project Management

Some years ago the Kate team introduced the “Session” feature.

This allows you easily to keep around different Kate sessions for different work tasks, like coding, web design, writing, …

Whereas I used that feature a lot at start during my normal daily work, I kind of no longer used it already since some years.

For my normal work pattern: Checkout a project, fix something in it or code an extension, then hop over to the next one, the session feature doesn’t really provide the right workflow.

My checkouts not always stay at the same location on disk, I keep multiple different checkouts of the same project around (or different clones) and I have too many different projects in company to create for all of them a session and keep any overview.

Even more years ago I wrote some project plugin for Kate allowing you to manage a more IDE style kind of project in Kate.

Instead of global sessions in your user account Kate allowed you to create project files which you can check in with your individual projects into your version control.

I purged that plugin later on again, as I lost interest in it because of one major design flaw: You really needed to use the UI to configure your project and add your stuff. That is REALLY annoying if your code base in in a state of flux or evolution and things really keep changing. (The removal wasn’t that well perceived, btw., sorry, but without maintainer, such plugins really cause a lot of pain.)

Now, here we are, six years later :) Given I still have my itch to scratch, I decided to give the project plugin a new try. But this time with a completely different approach: don’t create any UI to create/modify projects but come up with a simple file format for them that a Kate plugin can load.

And yeah, given my history as researcher in compiler construction area, what would be better than write just and other parser for some not understandable language? But no, I want to focus on the real stuff, make the description of the projects lightweight and easy to understand and not try to invent some new syntax yet again.

Therefore I settled with just using JSON to describe the project and started to implement some simple format, like:

    "name": "Kate",

    "projects": [
            "name": "KTextEditor",            
            "files": [ { "directory": "ktexteditor", "filters": ["*.cpp", "*.h"] } ]

            "name": "KatePart",            
            "files": [ { "directory": "part", "filters": ["*.cpp", "*.h"], "recursive": 1 } ]

            "name": "Kate",            
            "files": [ { "directory": "kate", "filters": ["*.cpp", "*.h"], "recursive": 1 } ]

            "name": "KWrite",            
            "files": [ { "directory": "kwrite", "filters": ["*.cpp", "*.h"] } ]

This small description should be enough to create the project “Kate” in my kate.git, containing 4 different toplevel parts: KTextEditor, KatePart, Kate and KWrite.

Without many hassle it just collects everything I need for daily work and constructs some tree structure (hehe, that part is not really done at the moment, but the output in my konsole looks OK).

Actually for my normal company work that format suites even better, as the projects there are normally even more fine grained than kate.git is (and for kate.git subprojects in kate/part/kwrite would even make more sense, above that is just an example).

Unfortunately there is not much done atm, beside some basic format handling in JSON and konsole output of the results, but I hope more will be done in the next weeks in my scratch repo.

Contributors, join and help the KDE e.V.


just yesterday I got asked by one long time contributor, if he can at all join the KDE e.V. or if he needs to do something special for that. He thought it would be more an invitation only club.

It’s not ;) Anybody who does contribute to KDE can join us.

KDE e.V. definition from its homepage:
“KDE e.V. is a registered non-profit organization that represents the KDE Community in legal and financial matters.”

If you want to have a vote on such stuff and are ok with the rules and goals of the e.V. like you can read on the e.V. homepage, please join.

You just need to fill out the questionaire on the e.V. page and send it to some e.V. member you know and that will support your application.

Even if you are no contributor, but want to support us with money to make our conferences & sprints possible (and our infrastructure), please take a look at our “Join The Game” campaign.

GSoC 2012: Vi Input Mode

Like last summer I am mentoring a student working on Kate’s Vi mode this summer. This year’s student is Vegard Øye from Oslo, Norway. I’ll let him introduce himself:

My name is Vegard Øye. I am a computer science student at the University of Oslo, Norway. I also have a bachelor’s degree in electrical engineering from Sør-Trøndelag University College in Trondheim, where I programmed for integrated circuits. It was a lot of fun, so I decided to embark on a grade with an even larger emphasis on programming.

My goal is to make modal editing more widespread outside of Vim. There is a Zen-like benefit to using a tool that does just what you tell it to – slicing and dicing text with surgical precision. My focus is not on adding new features to Kate (although I have implemented a few), but on sharpening existing functionality. In particular, I want to improve the integration between Kate’s vi mode and its extension system, as well as sort out various bugs pertaining to the vi mode.

Vegard has already done some really great work, and his changes should be trickling in to Kate’s git repository the next weeks. You can follow his work at