Category Archives: Common

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.

Python plugin developer guide, part 1

I’m a Python newbie, so if you are at least that good :-D, you should be able to dive in and write useful Python plugins for your favourite editor too! This is the first in what I hope will be a series of notes and tutorials to help you along the way.

Where can I find examples to steal from inspire me?

Any good developer knows that a good way to launch into a new area is to look at examples, so here is a list of places I’ve encountered.

Remember to respect others’ copyrights, and give credit where it is due.

Where do I put my code?

The Pâté Python plugin looks in several places to find usable plugins, you should be able to use the Python console to find a directory you can use for your developments. Select it, and press “Reload”:

Launch it from the View menu, and then ask KDE where your files should go:

Or, if that’s a bit hard to read, like this:

>>> from PyKDE4.kdecore import *

>>> print KStandardDirs.locateLocal(“appdata”,”pate”)


Try the directory

If the given directory does not exist, create it. Press Reload, and the new directory should be visible:

You are ready to create your plugin in the new directory! This plugin directory will be added to the initial value of sys.path used for all plugins.

Plugin structure and naming

Your plugin can be just a single .py file, such as “”, or multiple files contained in a directory. A single .py file is useful for simple things, but if you want to use .ui files or multiple Python files, a directory is recommended. If you use this option, the main plugin file must be named after the directory, so:

  • If the directory is called “console”
  • The main plugin file must be named “console/”

In the directory case, the directory is added to sys.path to load the main plugin file and other Python modules you may have. Since sys.path is searched by Python in order to load modules, having the same plugin in multiple locations would be very confusing. Pâté supports this by refusing to load identically named plugins; instead they are highlighted as being hidden:

This also means you can just copy one of the plugins supplied with Kate to get started!