All posts by Christoph Cullmann

Dr.-Ing. Christoph Cullmann is a Senior Software Engineer at AbsInt Angewandte Informatik GmbH. His work is focused on static analysis of both binary and source programs and the WCET analysis of embedded systems. In his spare time, he works on the KDE project and maintains the Kate editor application and component.

KDE 4.5: SmartRange => MovingRange

Dominik already blogged about the issues we have in KatePart with the current SmartRange/SmartCursor/Smart* interfaces that were designed during the early KDE 4.0 release.

Given that large amounts of the internal implementation are exposed to the outside in the interfaces, there was no feasible way to fix the issues with them. The problem with the not thread-safe behaviour could have been prevented by just stating the plain fact that multi-threaded access to the ranges doesn’t work, even thought there is a mutex in the interface exposed which should be locked to gain this safety. Still the real problems of the unchangable bad implemenation and design choices would have remained.

Given the fact, that the SmartInterface is an additional interface for a KTextEditor component and no component is required to implement it, we went the way to create a new redesigned additional interface, the MovingInterface.

In short: it is a stripped down version of the SmartInterface, which tries to avoid to expose any implementation details and is focused on provide the features actually used by other applications like KDevelop and have them working correct instead of providing just a mass of features, which doesn’t work at all in all corner cases.

For KDE 4.5, to not just break all applications which rely on the SmartInterface be implemented in KatePart, both interfaces will be implemented there.

As the SmartRange stuff somehow slipped into the CodeCompletionModelControllerInterface, we will provide a new version of this interface, too, version 3, subsuming 1 + 2, but without SmartRanges inside.

For KDE 4.6, KatePart won’t implement any longer the SmartInterface nor the old CodeCompletionModelControllerInterface(2), but:

  • MovingInterface
  • CodeCompletionModelControllerInterface3

If your application relies on any of these two interfaces to be implemented (or will be crippled without them), you should switch over to the new interfaces and require KDE 4.5, as soon as it is released.
That way the applications will just keep working with KDE 4.5 and higher.

KDevelop already is on the way to do so, hope others might follow (the interfaces are not widely used it seems, that at least means not that much applications are hit, KDevelop and Kile are for sure the major ones).

I can understand that this change might not be really liked by any project using the interfaces, but the plain facts are:

  • the code doesn’t work
  • it is not maintained
  • nobody still around really understands it
  • the BC of the interfaces disallows to fix the design flaws without a new interface

There will be more information for about the new stuff in the future,  but thought it is a good idea to remember people outside of the Kate development about the changes, before KDE 4.5 releases (which still will provide a KatePart implementing the old interfaces). shaping up now contains all articles from the old page still applicable to Kate in KDE 4 and in addition all blog entries of Dominik which are Kate centric.

Beside that it will aggregate the blog entries of Milian for Kate ;)

Still, a lot of work is needed. We already got an offer for help to beautify the page by a web designer, still content writers are missing. You have a nice short post about how to use Kate best? You have some howto? Just contact us or me in private. We can either give you an account on the page or just add your content if you like that more.

Design Ideas of the Kate::TextBuffer


  • Basic idea: text stored as lines
  • Lines hold text and additional data (like for highlighting)
  • Advanced Concept: Stores lines in blocks of xxx lines, to have better performance

Cursor Support

  • They will move on editing
  • Cursors can be combined to ranges
  • KateTextCursor will be stored in the buffer blocks


  • Each edit action must be encapsuled in a transaction
  • startEdit/endEdit will do this
  • Signals for starting and ending this transactions


  • After loading, buffer has revision 0
  • Each edit action which is no nop will lead to increment in revision number
  • Successful saving will reset revision back to 0

Editing Operations (only 4 different editing primitives)

  • Insert Text (inside one line)
  • Remove Text (inside one line)
  • Wrap Line (wrap a line at given position, create a new line with content behind wrap position)
  • Unwrap Line (unites the line with its predecessor)
  • Signals for all of these actions, containing the change (to allow to layer undo/swap file support/…) on top of the buffer

Load/Save & Encodings

  • Loading will try to use given codec, if that doesn’t work, try to detect the codec by the BOM at start of file or use fallback codec, if that again doesn’t work, given codec will be used again, and errors reported
  • Saving will just use the given codec

Unit Tests

  • Each of the above implementation details will be covered by unit tests
  • KateTextBuffer (+KateTextLine and Cursor) must therefor be usable without other components