Category Archives: KDE

Kate Love: HighlightInterface, Autobrace

Well, I have to admit: I didn’t spent much time developing the PHP plugin for KDevelop these past weeks. Instead I hacked on Kate:

HighlightInterface

I added another Kate interface, this time to access some of the highlighting information:

  • what’s the Attribute for a given default style right now? Default styles are those known from syntax files, e.g. dsKeyword, dsFunction,…
  • what are used Attributes in a given line and what range do they occupy?
  • what modes do we embed? E.g. PHP embeds HTML, JavaScript, CSS, …
  • what mode is used at a given Cursor position?

This made it possible to port the “Export to HTML” action to a real plugin. If you come up with other output formats I might add them, I wondered about LaTeX support… might do this at some point.

This should also make it possible to use KatePart in other applications and than export the highlighting to a different format, e.g. a Flake shape for Koffice. Afaik this is actually planned by The_User - lets see if it works out!

The other stuff gives huge potential in various places, but I fear it won’t make it in KDE 4.4. But think of it:

  • simple code completion based on keyword databases, dependent on the mode at the position where completion was requested
  • same as above for snippets (actually this will make it to 4.4).
  • insert your ideas here :)
Auto-Brace plugin

Jakob Petsovits created this gem of a plugin some time ago, yet it lived in playground was probably only used by few. I imported it to kdelibs, hence it will be shipped with KDE 4.4. It supersedes the limited “auto-brackets” feature of Kate and only adds braces when a newline gets added. I find this fits my personal coding habits much better than blindly copying brackets when they get added.

And I don’t just copied to kdelibs, I also added a few features:

  • automatically add a semicolon after the closing brace when we start a new struct/class in C++ mode
  • check for auto-brackets feature and disable it automatically

Also did this:

  • don’t add brace when current line contains namespace and a following line starts with class or struct (C++ mode only)
  • don’t add brace when current line contains class, interface or struct and the following line contains private, public, protected. C++ code is also checked for signals, Q_SIGNALS", other modes are checked forfunction`.

This should fix the bug for code like (note the indendation levels):

  1. namespace foo { // insert line here
  2. class bar;
  3. }
  4. class asdf { // insert line here
  5. private:
  6. ...
  7. };

first experience with Archlinux

So, I kinda messed up my desktop right after the upgrade to karmic, because I was too greedy for performance and converted my root file system to ext4. Well, that worked like a charm on my laptop, but it broke my desktop. This is in no way karmic’s fault, it’s my own misbehavior. Thankfully I could rescue most of my data.

Since I’d had to reinstall anyways, I decided to finally try out Archlinux. I find the rolling release mantra very intriguing. Together with a “simpler” packaging, namely no splitting between -dev and -dbg packages like debian/ubuntu does, this is destined to be a good environment for a developer. I always hated it to track down missing -dev packages when compiling software. And don’t get me started on outdated software in repos… I just compiled kdelibs and the only missing build dependency was hspell, that I don’t need anyways. Under Jaunty I had to compile stuff from kdesupport to fulfill updated dependencies. And the list of not-found optional dependencies was huge, since I did not spent time to install all those -dev packages by hand…

My first impression of Archlinux is very good so far. I also finally migrated to 64bit wich works like a charm, no issues with flash or anything. Since I never used a 64bit Ubuntu/Debian I’m not sure, whether the perceived performance increase is due to the switch to 64bit or whether Archlinux optimized packages are responsible. Probably both. Nevertheless I can safely say that my system feels snappier than before.

Of course, the installation and initial setup is not as straight forward / easy as with Debian/Ubuntu: Yet it’s no big deal for anyone with some Linux experience. And, once everything is setup, you are running KDE again, so no real difference. Thanks to the Chakra team for kdemod, it works like a charm!

I might have spent a bit more time during the installation / initial configuration, but I think this would have happened also if I’d installed any other distro I’ve never used before, like OpenSuse or Fedora.

Oh and since I can install sudo I can keep my old habits. Neat.

The only thing I miss so far is aptitude with it’s straight forward command structure. Yaourt/Pacman is fast and nice, esp. with pacman-color, but the commands don’t feel as straight forward to me… Personal preference I’d say.

To conclude: Archlinux is very nice, I can wholeheartedly recommend using it so far. Probably nothing for a novice Linux user, yet perfect for advanced users. Very good as a development environment. Fast. Up to date. I like it :)

Now I can finally continue hacking on Kate/Kdelibs again :) I’m currently in the process of refactoring Kate’s implementation of the TemplateInterface. Even in it’s current state it already implements features like mirrored snippets and the like. But once I’ve finished with the cleanup I will try to implement some more of the features that are found in e.g. yasnippet for Emacs. I really wonder why nobody else did that already…

Once this is finished, you can expect that I will deeply integrate that feature in various places in KDevelop, especially for code completion, snippet plugin etc. pp. Stay tuned!

System Load Viewer

Last year I’ve blogged about the missing system monitor with the three bars for the panel and about its port to Plasma. Meanwhile other developers also did a port called System Status. In a collaboration with them we finally have the applet back in KDE’s subversion, the name is now “System Load Viewer” and it uses the data engine “systemmonitor” that already exists in KDE 4.2.
So if you want to have the plasmoid for your KDE4.2 desktop, it should be straightforward to compile/install.
On the screenshot you can see the plasmoid in action. There are two instances, one on the panel and one on the desktop. The one on the left is the KDE3 one.

It’s worth to mention that the plasmoid already supports more featues than the KDE3 version. Features include:

  • show all cpus (for computers with multicores)
  • tooltip updates continuously
  • nicer visualization (maybe needs some more tweaks)

As soon as the KDE 4.2 freeze is over we’ll have to see where we can put the plasmoid to make sure it’s available for KDE 4.3 :)

API documentation & refactored kdelibs/kdeui

During the last weeks/days the directory structure of especially kdelibs/kdeui got a major overhaul: in KDE 3 all files of a module were in the same directory which was more or less a mess as you did not know immediately which files belonged to the same category. kdelibs/kdeui in KDE4 has a rather clean structure now (similar to the one in Qt) by using subfolders like

  • actions
  • dialogs
  • widgets
  • xmlgui
  • several others…

Compare this to KDE3′s kdelibs/kdeui structure. For KDE4 this is a huge benefit, as we have clearly defined groups. We already had lots of discussions in the past about API documentation and this is exactly where the new structure is important: In Qt every class usually belongs to a group (example). Our API documentation tool doxygen of course supports grouping, and now it is even easy to know which class should be in which group. For instance, all classes in the widgets directory should be in the ‘Widgets‘ group, and then maybe even more fine-grained divided into sub-groups.
By the way, we have a policy that every widget in kdelibs has a screenshot to immediately see how it looks like – another nice way to get involved :)
All in all this is really awesome and I’d like to thank all involved developers. Next prey is kdelibs/kdecore? =)