Category Archives: Developers

MovingRanges moving on ;)

As with any new code, during adoption bottlenecks show up.

For example the rendering of text lines with many ranges inside was quiet slow. This is now partly addressed by Milian Wolff, thanks a lot.

An other bottleneck was the assumption, that it is fast enough to hash the ranges just by their block and iterate over all of them to search the ranges matching a specific line. This does scale well enough for KatePart itself, but KDevelop creates multi-thousand ranges for small documents. To improve this, an internal special mapping was implemented by David Nolden for ranges which don’t span more than one line. For them an efficient line => range mapping is easy and not to costly.

If both changes are tested a bit more, they can be backported in time for KDE 4.5, which will allow a good usability of KatePart for KDevelop once again after the rewrite, given other bugs are fixed.

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).

GSoC – Swap Files for Kate

Hello,

As mid-term evaluations have started, I would like to show my current state of GSoC project, because I’ve never found the time to do it.

The swap file feature is implemented, except for the view differences feature and few TODOs. Some more testing need to be done, though. Below are some screenshots of how it works.

When you start editing in a document, a swap file for the document is created (“.swp.originalFileName”). If Kate crashes and the user didn’t save the changes, the swap file remains on the disk.

On the load of the original file, Kate checks if there is a swap file on the disk, and if it is, a warning bar pops from the top, asking if you either want to recover the data loss, discard it or view differences. If the recover button is pressed, the lost data is replayed. Otherwise, if the discard button is pressed, the swap file is removed from the disk. This also happens on normal close and on save of the original file.

Many thanks to Christoph and Dominik who helped me get it through.

Kate: Scripted Actions

Finally, I came around to implement scripted actions for Kate in KDE SC 4.6. Let’s take a look at how this works. When Kate starts, it searches for $KDEDIRS/share/apps/katepart/script/ for *.js files. As example, let’s take a look at utils.js there:

/* kate-script
 * author: Dominik Haumann
 * license: LGPL
 * revision: 3
 * kate-version: 3.4
 * type: commands
 * functions: moveLinesDown
 */

function moveLinesDown()
{
  var fromLine = -1;
  var toLine = -1;

  var selectionRange = view.selection();
  if (selectionRange.isValid() &&
      selectionRange.end.line < document.lines() - 1)
  {
    toLine = selectionRange.start.line;
    fromLine = selectionRange.end.line + 1;
  } else if (view.cursorPosition().line < document.lines() - 1) {
    toLine = view.cursorPosition().line;
    fromLine = toLine + 1;
  }

  if (fromLine != -1 && toLine != -1) {
    var text = document.line(fromLine);

    document.editBegin();
    document.removeLine(fromLine);
    document.insertLine(toLine, text);
    document.editEnd();
  }
}

function action(cmd)
{
  var a = new Object();
  if (cmd == "moveLinesDown") {
    a.text = i18n("Move Lines Down");
    a.icon = "";
    a.category = "";
    a.interactive = false;
    a.shortcut = "";
  }

  return a;
}

function help(cmd)
{
  if (cmd == "moveLinesDown") {
    return i18n("Move selected lines down.");
  }
}

What happens is the following:

  1. the header tells kate that there is an exported function “moveLinesDown”
  2. so when Kate Part is loaded, it calls “action(moveLinesDown)” to check whether this function should be exposed in the GUI. Here, we return the action info that includes the displayed text, an icon, a category, whether the script needs user input (interactive) and a default shortcut. Of course, you can change the shortcuts, and also configure the toolbars to show the actions.

With this, every user is able to script arbitrary editing functions for Kate Part. We don’t have to implement all those helpers in C++ anymore. The result looks like this:
You can have this already now, you just have to use the development version of Kate :)