For me, it (still) feels very unnatural to talk about us as KDE. I’m still thinking in terms of the KDE community; and the KDE Project releases the KDE Desktop (or just KDE). I’m also fine with the KDE Workspace and other specialized variants. However, the login manager now also shows the term KDE Plasma Workspace. In my very own humble opinion, this is already too much of buzz words.
At university, I’m helping out with system administration. And since I’m very familiar with KDE, I fix all KDE related issues (and usually enjoy doing so). We have lots of colleagues that never used KDE. Now, try to explain the term Plasma… Well, it’s a desktop shell – also too complex. It’s the desktop, with all the icons and panels. That’s more understandable But next, a dialog pops up with some status messages: Akonadi. Well, try to explain the term Akonadi. It’s similar with other technologies. Explain what Nepomuk is doing with the difference to Strigi… When I try to explain what’s happening, and what all these components do, I sometimes feel
pretty much stupid uncomfortable using these words.
It is similar with the term KDE SC. As part of the rebranding, the KDE Software Compilation or short KDE SC was introduced. I can understand that we build a platform and our target is more than just the Desktop. But talking to other people, I feel stupid saying KDE SC. For me, it simply is (and probably will always be) a no-go. But it changed already, to the KDE platform, or maybe I misunderstood that ?
Funnily, I think it’s fine to use application names such as dolphin, kate, amarok and what not. So to some degree, I’m certainly simply used to these terms. But still, it feels right, also when talking to other users. We have to be very careful to use fancy names in very prominent places. Ah, and with respect to naming applications, there is a similar discussion on kde-core-devel right now 😉
As you may know, Kate supports the concept of document variables, also known as modelines. In short, document variables can be used to set Kate settings local to a file. For instance, this is useful for settings specific indenter options than the ones defined in Kate’s settings dialog. Assume you work on two projects, the first indents with spaces and the second with tabs, then you can simply add a modeline that contains the specific document variables that set the specific indentation properties.
While the concept is very mighty, it is not intuitive to use: You have to know the exact syntax and correct varialbes and their valid values.
To improve this for the next KDE release (v4.8?), Kate gained a variable / modeline editor this week:
If you click the Edit button, a list view pops up showing all valid document variables with the valid values. Right now, this editor is included only in the “Modes & Filetypes” config page. However, the idea is to support it in the context menu over a Kate modeline in the text editor area as well.
Now that the next version of the KDE platform is branched, it’s time to have a look at all the changes in Kate in KDE 4.7.
Current State of Kate
- In KDE 4.6, we replaced the document list by the new File Tree. We got relatively few critical reports, meaning that the file tree seems to work pretty well for the majority.
- Kate has two GSoC projects at the moment: Rewrite of the code folding, and Improving Kate’s vi mode. The work done in both projects will be available in KDE 4.8, so we are already working on the next major KDE release.
- About 6 Kate developers are present at the annual KDE conference.
- A year ago, the Kate homepage was redesigned. Looking back the last year, we can say that this has been a success.
Just in case you missed it: you can read about Kate’s state 6 months ago here.
We’ve managed to push our bugs down from ~430 to ~310 during the last two days. Some bugs are not valid anymore, but lots of bugs also really have been fixed. So in KDE 4.7 we will have the best Kate release ever