So, for me the KDE four core meeting in Trysil has finished today. It was an amazing experience, meeting people for the first time and seeing what we could do when we concentrated (most) all of our efforts on improving KDE4.

This evening in Trysil we had a long meeting to discuss goals for KDE 4.0, both generally and specifically.

Topics covered did not contain many surprises, most issues were already covered in the planning documents already existing in the wiki and svn. Prioritising our time is of course important, and in rough descending order they were thought to be:

Well, it's been ages since I've blogged - generally I feel that code speaks louder than blogs :) However, I think it's time to do some catching up.

Currently the rest-of-kde porting is proceeding after the massive KAction changes I recently committed to kdelibs. Now that the snapshot carries the changes too, it's starting to get heaps of testing, which is so far standing up pretty well (only a few bugs reported to date, the significant bug already fixed).

Being on holidays certainly gives you time to reflect on what new features you'd like in your text editor :) I've come up with something which I hope will help make using a text editor a better experience by providing more assistance to the user... input filtering.

I've been working on something pretty big for katepart for a while now, but it's just struck home how widely applicable this new idea will be for apps utilising the KTextEditor api.



The whole thing started when I was looking for a way to enable custom programmatic syntax highlighting. I first implemented a smart cursor which retained its relative location while the text around it was edited; then extended this into a pair of smart cursors to define a "range" of text. These objects give forth plenty of useful, convenient signals, such as changed(), moved(), etc. This looked like a promising way of implementing custom HL.