KDE 

Phew, I just finished some last-minute backports to the KDE 4.3.5 branch. Lets hope the bug fixes I and pletourn did are as good as they look. Expect a much more stable Kate for 4.3.5 & 4.4! We managed to fix two bugs which are potentially the cause for dozens of bug reports, all seemingly random. Lets see whether our fixes hold up to our hopes!

Other than that: You should look forward to Kate scripting (with JavaScript) in 4.4. It’s dead simple but actually useful. In the utils.js file we ship with Kate there are now the following tools (all operate on the selection or - if none exists - on the whole document):

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.

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.

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…

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? =)

Text editors and line edits support the so-called triple clicks according to [1]1. The document says

• Triple Click: Select the targeted row. […]

It is unclear whether the “targeted row” includes the trailing linebreak. Kate Part selects the targeted line including the linebreak. You get the following behavior:

• If you move the selected row with the mouse, you usually have the linebreaks right. The same applies for copy/cut & paste. If you are used to it, it really is a nice feature.

While this behavior is pretty straightforward, it is not widely in use. If you look at text edit widgets like in firefox, konqueror, Qt, KWord or OOo you will notice that they do not include the trailing newline character.