dhaumann

Moving my Blog

2010-07-09T13:58:00.002+02:00

Since we have a new Kate Homepage, I''ve moved all my content over. Now the kate homepage at least has lots of Kate related content :)

Kate: Scripted Actions

2010-07-09T11:04:00.005+02:00

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 Array();
  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:

the header tells kate that there is an exported function "moveLinesDown"
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 :)

Enjoying Tampere

2010-07-07T00:11:00.008+02:00

As always, the KDE conference has its funny sides, as you can see on the photo: 4 Kate developers shaping the future of the (as you all know) most awesome application: Kate :-)

A Flashback of Kate in Gitorious

2010-06-24T22:32:00.003+02:00

Back in February, I blogged about Kate's move to gitorious. The main reason for this move was to make building Kate as easy as possible. If you want to build Kate as part of KDE, (as of now) you have to compile kdesupport, phonon, dbusmenu-qt, kdelibs, kdepimlibs, kdebase for kwrite and kdesdk for the kate application. Getting all this done is a huge effort, especially if you are new to KDE development (I very well remember my own times spending weeks to get everything going. Be aware of new contributors might now close to nothing about KDE and all the dependencies!).
As getting new contributors is essential for keeping a project alive, the barrier to get involved should be as low as possible. And exactly this was achieved by moving all pieces to one place (this was gitorious for us). Building Kate is so simple right now that we can even make bug reporters build Kate out of the box. This helps a lot, and even results in patches from time to time. We also got quite some merge requests.
There were several voices at that time that considered moving "away from KDE" was very bad. However, this is not the case, as Christoph is synchronizing all the changes in KDE's subversion and gitorious almost every day. This is certainly not optimal, but looking back at the last months, we can say it was worth it.
KDE is moving to git.kde.org in the near future. This also raises the discussion about how KDE's source code will be organized. Speaking for Kate, we certainly want to have all of Kate's code in one place, just as it is now with gitorious, no matter what :) I hope we can find a solution the KDE community can live with. To be discussed, maybe in Tampere in two weeks? :)

Kate: Debugging with Qt-Creator

2010-06-19T11:48:00.004+02:00

Let's have a quick look at how to debug Kate and KWrite with Qt-Creator. First, make sure you meet the requirements:

build Kate according to this tutorial
install Qt-Creator (in my case this is version 2.0.0rc1)

Setup the Kate project Qt-Creator once like this

start Qt-Creator: ~/kde/run.sh /path/to/qtcreator/bin/qtcreator
invoke File > Open File or Project and choose ~/kde/kate/CMakeLists.txt
Build Location: choose ~/kde/build
Run CMake arguments: choose ../kate -DCMAKE_BUILD_TYPE=debugfull -DCMAKE_INSTALL_PREFIX=~/kde/usr
click the button "Run CMake" and then "Finish"

Start debugging like this

click the "hammer" icon button on the very bottom left to compile Kate
click the "computer" icon button (3 icons above the hammer icon) and choose "kate" (or "kwrite") in the Run combo box
choose the "Debug" icon in the left pane
invoke "Debug > Start Debugging (F5)", now Kate starts
open part/document/katedocument.cpp in the file tree view on the left
go to the line "KateDocument::insertText" and click "Debug > Toggle Breakpoint (F9)"
now if you type a character in Kate, Qt-Crator will halt in KateDocument::insertText
chose "Debug > Step Opver (F10)" (and "Debug > Stip Into (F11)") to step through the code
click on "Locals and Watchers" in the debugging pane on the bottom and you see the values of local variables

Happy debugging :)

Kate: Code Folding Crash

2010-06-10T22:55:00.003+02:00

We still have a crash in Kate's code folding code; no one was able to find a proper fix, yet. So if you want to get your hands dirty, just build Kate, find a fix and be the hero of all Kate developers :)

Update: Fixed by Stefan Schenk in this commit for KDE 4.5. Awesome! :)

Kate Internals: Smart Cursors and Smart Ranges

2010-04-28T17:53:00.002+02:00

SmartCursors and SmartRanges in KDE 4.0 - KDE 4.4

Since KDE 4.0 the KTextEditor interfaces have so called SmartCursors and SmartRanges. A SmartCursor is a text cursor (i.e. a line/column tuple) , which is bound to a text document. When editing the text document, the cursor is automatically moved such that it maintains its position. You need this for the displayed text cursor in a view for instance. If you type text, the cursor automatically moves.
A SmartRange consists of two SmartCursors: start and end. We use that for instance for the text selection or the inline spell checking, or KDevelop uses it to add arbitrary highlighting to parsed C/C++ code. Again, if you modify text in the document, the text range automatically moves, expands or shrinks.

The concept of SmartCursors and SmartRanges is doubtless very useful. However, for KDE 4.5 the Kate developers came up with an alternative implementation that will even deprecate the SmartCursors and SmartRanges in KDE 4.6. The reason for this is that the current implementation has several problems, which we will discuss in the following.

API Usage

The SmartRanges API can be used in very wrong ways. For instance, the SmartInterface has the two functions deleteCursors() and deleteRanges(). Besides that, a document reload also deletes all SmartCursors and SmartRanges. Both cases lead to a dangling pointer if you use SmartCursors or SmartRanges. Hence, whenever you use them, you always need a so-called SmartCursorWatcher / SmartCursorNotifier and SmartRangeWatcher / SmartRangeNotifier, which tell you that your SmartCursor or SmartRange is about to be deleted. Watcher and Notifier basically do the same thing. Besides deletion notification, they also tell you more e.g. that the SmartCursor position changed. If you use a notifier, those notifications are sent via signals. If you use a watcher, you have to overwrite virtuals. That is, we have two different concepts that basically do the same thing. If you use thousands of SmartRanges e.g. for arbitrary highlighting, we have possibly thousands of those emits, which does not really scale.

The API also allows to have parent/child relations, i.e. a SmartRange can have children and a parent. It is possible to traverse this hierarchy, and again since you get the pointers you can delete arbitrary SmartRanges or SmartCursors. Another reason why you always need a notifier or watcher. And if you have a notifier/watcher, you always have the signals emitted when e.g. a cursor changes, as explained above.

Further, we have lots of places where we use reference object KTextEditor::Cursor& as parameter. This const reference-object signals that it does not change. But due to SmartRange deriving from KTextEditor::Cursor, this object might also be a SmartCursor. So despite of being declared as a const object, it may change its position behind your back. This may lead to unexpected behaviours in e.g. loops where the line or column of the cursor is assumed to be constant. This is a problem in almost all functions in KatePart, so passing SmartCursors as Cursors is a very bad idea, but of course allowed.

Scaleability Problems

As mentioned above, you always need a Notifier or Watcher for all SmartCursors and SmartRanges. This will emit lots of signals you probably rarely need. Still, there is no way around it. This is a huge overhead, it simply does not scale.

Implementation

The implementation is really complex and rather undocumented in most areas. Unfortunately, only very few (or maybe even no one) really understand the code. Besides that, it is very fragile. If you change something, you might break the code. Hence, we often heard similar comments like "don't touch the code, otherwise it will break". Such comments alone already indicate that the current implementation is not maintainable. Unmaintainable code is bad, especially in open source projects (this is not a good way to gain new developers at all). There are other downsides of the current implementation: SmartCursors need a lot of memory for each instance; there are lots of features like animations for SmartRanges, which make the code even more complex; redundancy of watchers and notifiers bloat the code and influence the runtime behavior.

Threading

It seems there was the idea of making the KTextEditor interfaces thread safe. The SmartRanges interact with the content of the document, e.g. querying lines count and line length of lines in the text buffer. As this is done by other threads we need correct locking in all places: in document content changes, in smart cursors, in smart ranges, in the painting routines, etc. The current state in KatePart is that not all functions do the right locking. That's why we have lots of asserts/crashs. KatePart already has more than 150 lockings at the moment, but they still do not voer problems. And very few developers (or no one?) really know when to lock and when not to. This is especially complex since we want to ensure that the locks are not hold while emitting signals or calling functions provided from the outside as callbacks, this is still not done completely right, too.

If you think about Qt, the GUI widgets are also not thread-safe, they all live in the main thread. And if you need data in other threads, you always use queued signals. This is pretty much what we experience in KatePart now. Not enough locking? Too much locking? In other words: It's far too complex to make the KTextEditor interfaces thread-safe...

Threading and Revisions

Now to another issue in the implementation. KDevelop uses KTextEditor::Ranges in the parsing thread. Think of the following use case: KDevelop gets all the document text in the current revision (or version, if you prefer). Now it takes some time until the parsing is finished. When it's finished, KDevelop uses the Ranges (which initially belong to the old revision of the document), and then translates those ranges to the current version of the text document (this is simple: Just track all edits inside KatePart (delete, insert, wrap, unwrap) and apply those transformations to the ranges). Now we transformed ranges from an old text revision to the current text revision. This means KDevelop does not have to parse everything again, as it knows exactly which parts changed. Awesome indeed :) However, now comes the problem: To transform Cursors and Ranges between revisions, you have to tell the SmartInterface about the revision you are working with. This is done via SmartInterface::useRevision(int). The API documentation says: Tell the smart interface to work against the given revision when creating cursors and ranges. That is, if you call useRevision() once, all succeeding calls like newSmartRange() etc are working in the past (at that revision). Also kind of cool, since useRevision() works locally in each thread. That is different threads don't influence each other. But there is huge problem with this: Think of a KTextEditor user (KDevelop, Kile, ...) uses useRevision() in the main thread. Then all succeding calls of e.g. newSmartRange() use an old revision instead of the current one. Hence, KatePart itself is completely broken in that case. (This case is now catched via a qFatal() in KatePart). But again this shows that multi-threading simply complicates the matter a lot. It would have been much easier to say transformRange(int fromRevision, int toRevision) instead of just one translateFromRevision() that translates the given range against the revision specified through useRevision(). Hence, the current API is unfortunately pretty much broken by design.

A necessary Step?

Often it's hard to get things done right in the first try. So maybe the issues above are a necessary step to a much better implementation. And that is exactly what happened in the last two months: We have new interfaces called MovingInterface, MovingCursor and MovingRange. For feedback there is MovingRangeFeedback, which uses callbacks for notification (no signals by intention). All those classes have unit tests. KatePart in KDE 4.6 will not implement any Smart* interface anymore. Hence, KatePart will be completely single threaded again. We already started to remove several thousands of lines Smart* code that was never used/finished. Much more will follow immediately after the KDE 4.5 release. This means all developers using Smart* from the KTextEditor interfaces should migrate to the Moving* pendents for KDE 4.5 already, if possible.

I'll provide very detailed information about the Moving* implementation in further blogs during the next month.

Kate XML Completion Plugin

2010-04-27T21:45:00.005+02:00

A while ago I've blogged about the Kate's most powerful plugins: the XML completion plugin. Thanks to Tomáš Trnka this plugin is back alive with all its features since today and compiled by default in trunk: It will be included in KDE 4.5. Yay! :) And if you need it already now for KDE 4.4, you can build Kate yourself very easily according to this howto, without touching your global KDE installation (probably interesting for KDE documentation writers!). Have fun!

Quick Compiling Kate in a stable KDE Environment

2010-04-17T14:10:00.006+02:00

Since all of the Kate code is now co-hosted on gitorious, it became very easy to build Kate in your stable KDE >= 4.4 environment. This means you can run the newest version of Kate with very few effort. Just give it a try and do the following steps:

make sure you have the following packages installed: git, cmake and kdelibs development package (on openSUSE this is git, cmake and libkde4-devel)
create and change into a KDE development directory:
mkdir ~/kde; cd ~/kde
get a copy of the Kate code:
git clone git://gitorious.org/kate/kate.git
create and change into a build directory for compilation:
mkdir build; cd build
run the configure process with cmake:
cmake ../kate -DCMAKE_BUILD_TYPE=fulldebug \
-DCMAKE_INSTALL_PREFIX=~/kde/usr
compile Kate:
make
finally install Kate:
make install

That's all! This installs Kate locally into the separate directory ~/kde/usr, so that your global KDE installation will not be touched at all.

Now on to starting the newly compiled Kate. Create a file ~/kde/run.sh with the following content:

#!/bin/bash
export KATE_DIR=~/kde/usr
export PATH=$KATE_DIR/bin:$PATH
export LD_LIBRARY_PATH=$KATE_DIR/lib:$LD_LIBRARY_PATH
export KDEDIR=$KATE_DIR
export KDEDIRS=$KDEDIR
export XDG_DATA_DIRS=$XDG_DATA_DIRS:$KATE_DIR/share
# update KDE's system configuration cache
kbuildsycoca4
# start app
$@

Now you can run the compiled Kate version with ~/kde/run.sh kate. Just calling kate directly will start the system version of Kate.

Your copy of Kate contains all of the Kate code, i.e.: the KTextEditor interfaces, Kate Part, KWrite and the Kate Application. Feel free to send patches to our mailing list kwrite-devel@kde.org. And join #kate on irc.kde.org :-)

Note for KDE developers: All the changes in git are merged back to KDE's subversion repository in a timely manner. So don't worry about Kate moving away from KDE; this is not the case.

(Updated on 2010-04-17: Allow installation into local directory.)

Kate Internals: Text Buffer

2010-03-02T23:17:00.004+01:00

Right now, in Kate's gitorious repository we, or rather mainly Christoph, is rewriting the heart of Kate: The text buffer. In this blog I'll explain how the text buffer works in detail. After reading, you'll be able to understand the code. And be warned: Probably you will be desperately amazed about its awesomeness! So this is a must read :^) The following content is based on the notes for design ideas for the new text buffer.

Storage. Kate Part internally stores the content of a text document as a QVector of text lines. Each text line holds the text in a QString object as well as additional data like color attributes for highlighting. Inserting and removing text lines implies inserting or removing items in the QVector of the text lines. This is can get slow when there are thousands of text lines in a document, because QVector has to move the memory every time. Thus, to keep text operations fast, Kate splits all text lines into several text blocks: Each text block contains a certain amount of lines (e.g. 256). The expense of memory movement is then always limited. When a text block grows too much, it is automatically split. When the amount of lines in a text block shrinks, it is merged with the previous text block. In other words, Kate's text buffer automatically balances the text blocks. The basic idea of Kate's text buffer, the text blocks and text lines looks like this:

Text Cursors and Ranges. Text manipulation always takes place at certain positions in a text. Such a position is called a text cursor. Each text cursor is defined by a line and a column. Further, to specify e.g. text selections, we need text ranges. A text range has a start cursor and an end cursor. For instance, if you have two views of the same document, you want the cursor in the 2nd view to keep its correct position in the text if you insert text in the 1st view. Thus, text cursors have to be kind of intelligent. Whenever text changes, each text cursor needs to be moved. As a text range just consists of two text cursors, we will focus only on text cursors for now. The question is how to implement this efficiently? If we store all text cursors in a list in the text buffer, we have to iterate over all text cursors on every editing operation. This obviously does not scale for thousands of text cursors (KDevelop for instance uses thousands of text cursors for the highlighting). The solution is the same as with the text content itself: Let's just put a list of all text cursors in a text block to the text block itself. During text editing, we only have to adapt all text cursors of a single text block instead of all text cursors in a document. This looks as follows:

Editing Operations. When editing text, you usually have only four different types of text manipulation:

insert text at a text cursor inside one line
remove text at a text cursor inside one line
wrap line at a text cursor (e.g. by hitting <return/enter>)
unwrap line (e.g. by hitting <backspace> at the beginning of a line)

Those editing primitives are implemented in the Kate::TextBuffer and Kate::TextBlock and take care of balancing the text blocks. For each one the set of text cursors in a text block has to be adapted. Of course, corner cases need to be taken into account: For instance, unwrapping the first line in a text block means that cursors in the first line need to be moved to the previous text block. All editing primitives emit a signal, such that additional layers later can track what happens. For instance, the undo/redo system needs to know all editing operations. Or on top of that we could implement vim like swap file support, i.e., track all changes from the beginning, and if Kate crashes, replay all the editing primitives on the original files.

Transactions. A transaction consists of several of the four editing operations. For instance, if you select text and then move it to another location in the document with drag & drop you want this to be grouped together to a single text operation on undo/redo. (The text operations in this case are unwrap lines and remove text, then insert text and wrap line). To be able to specify which parts of text operations belong together, the text buffer provides two functions: startEditing() starts a transaction and finishEditing() closes it. Those functions use reference counting, so you can call startEditing() multiple times and only the last finishEditing() completes a transaction. Again, signals are emitted e.g. in finishEditing() such that other layers (undo/redo system) are notified about this.

Revisions. As an easy way to check whether a document changed you can get the current revision of the text buffer. The revision is simply an int64 starting with 0 after loading a document. The revision is incremented in every of the 4 editing primitives. This way you don't have to listen to multiple signals like textInserted() and textRemoved(). This could be useful for e.g. KDevelop's background parser: Parse a file. When done, check whether the revision is the same. If yes, parsing was successful. If not, parse again. This is how QtCreator does it. Easy and straight forward.

Unit Tests. The text buffer, text block, text line, text cursors are all designed such that unit tests can be written. Hence, each of the above implementation details will be covered by unit tests.

Further ideas. As mentioned previously, the design of the text buffer leaves room for further features. For now, let's face two ideas:

Vim like swap files: If Kate or the application using Kate Part crashes, the unsaved data in the text document is lost. Vim has a backup mechanism called 'swap files' to recover from crashes to avoid data loss since years, and it works as follows: Each of the 4 editing primitives explained above are streamed into a separate file. When you save a file successfully, the swap file is cleared. If a crash happens, vim loads the original text document and then replays all editing operations in the swap file. This way the current unsaved editing state is recovered; no data is lost. Since the text buffer emits all necessary signals, implementing this feature is kind of trivial. Any takers?
Right now, the highlighting works in an extra class, accessing the text buffer's text lines and setting the text attributes such as the color. As idea, we could also derive a class Kate::HighlightingBuffer from Kate::TextBuffer and do the additional modifications in the derived class instead of an extra class. We'll have to see whether that makes sense.

Please Contribute.

join #kate on irc://irc.kde.org
checkout the code base, clone it, create branches, and merge back!
other kate internals: undo/redo system (little bit outdated, but all in all still valid)

Kate Partly Moving to Gitorious

2010-02-27T16:55:00.004+01:00

We are about to move the applications Kate and KWrite as well as the libraries KTextEditor and Kate Part to gitorious. Christoph is working on the migration right now in order to keep the development history. Things look good so far, so the migration is soon finished.
We have discussed a bit about the migration to gitorious on the Kate Developer Meeting and Christoph came up with this mainly because building only KTextEditor, Kate Part, KWrite and Kate is much faster and easier compared to building the KDE modules kdesupport, kdelibs, kdepimlibs, kdebase, kdesdk.
I myself remember the time where I started KDE development, and it took more than two weeks to have a first successful build of KDE. You have to learn so many things at once, like revision control, lots of so far unknown software, and what not. Talking to other developers verifies this. In other words: Getting into KDE development is not easy and straight forward.
Moving to gitorious removes this barrier for Kate development: You just checkout the Kate repository and that's all you need. It would be nice if you join Kate development and contribute patches :)
What does that mean for Kate in KDE? Nothing changes. We will merge the changes in Gitorious back to the main KDE development line and vice versa.

The Power of Developer Meetings

2010-02-17T14:15:00.004+01:00

Since several years, we have lots of small developer meetings in the KDE project, gratefully supported by the KDE e.V. There, developers of a certain project (e.g. KMail/kdepim, Plasma, you name it) meet to discuss further plans and to push the project further. From experience we can tell that those meetings are really beneficial in several ways:

Social aspect: You get to know the other developers involved in the project in real life, which is a great motivation factor. This also happens at KDE's annual conference Akademy, although there are a lot more people.
Productivity: Since you are sitting next to each other discussions about how to do what are very focused. It's amazing how quickly a project can evolve this way. (I haven't seen such focused work in companies, yet. I guess the variance in the knowledge of people involved is higher. And the motivation is usually very different).
Knowledge Transfer: Since participants are experts in different areas, discussions lead to knowledge transfer. This is essential, as sometimes developers have very few free time to contributes to a project. Spreading the knowledge helps a lot to keep the project alive.
Steady Contributions: We are always open for new contributors. Just send a patch, get commit access and join development. Experience shows that participants of a developer meeting usually contribute for years to come.

Enough said, here is what happened the last three days in Kate:

There are even more changes I left out. Most of those changes will be in KDE 4.4.1. If you want to help, join #kate in irc.kde.org!

Developer Meeting: More on scripting Kate

2010-02-17T13:57:00.006+01:00

We are 10 people here at the developer meeting in Berlin. Kate, KDevelop as well as Okteta see a lot of commits. I'll mainly talk about what's happening in the holy Kate land, though :-)
Yesterday I closed a bug requesting an "unwrap" feature in Kate that works like "Tools > Join Lines" but maintains paragraph separation, i.e., empty lines are not removed. This feature is implemented now in javascript. Further infos:

To run the script simply switch to the command line (F7) and write "unwrap". If you have further ideas about useful scripts, don't hesitate to start hacking right away, see also

how to extend Kate with scripting

Fixes with regard to the scripting support in the last days are

Those fixes will be in KDE 4.4.1. More to come in other blog entries :-)

Kate XML Completion Plugin: Help Wanted

2010-01-17T12:58:00.003+01:00

In KDE3 Kate had a plugin called "XML Completion Plugin". It was able to list XML elements, attributes and attribute values and entities in a completion popup menu depending on the currently active DTD. For instance, it was able to complete all your KDE/docbook tags and, thus, was one of the best tools for writing KDE documentation.

Unfortunately, this plugin has not been ported to KDE4, yet. So this is a request for developers: Please someone pick it up and make it available for Kate in KDE4.

The location in svn is: trunk/KDE/kdesdk/kate/plugins/xmltools
Just enable this folder in the kate/plugins/CMakeLists.txt file and start porting it. The code completion interface changed quite a lot, but there are other plugins and good api documentation (KTextEditor interfaces, Kate Application interfaces) where you can have a look at how things work.

Having a working XML Completion plugin for KDE4.5 would be awesome.

Scripting Kate

2009-11-01T15:04:00.004+01:00

In my last blog I explained Kate's scripting features in KDE 4.4. To better understand how scripting can be used let's look at some use cases.

join lines: This feature request wants the action "join lines" to not join different paragraphs, i.e. not remove empty lines. We have not implemented this wish, as there are probably users who prefer the current behaviour. This request can be fixed by writing a small script that joins the lines according to the user's wishes.

reformat paragraph: An intelligent reformatter for paragraphs. Should be rather straight forward to implement.

XML tools: In KDE3, Kate once had a xmltools plugin. Unfortunately noone ported it to KDE4. The plugin provided lots of very useful features for xml editing. For example, you could select text and then wrap it with xml elements, e.g. "text" would become "<para>text</para>". This is a perfect example for a command line script as well. Any volunteers? :)

Scripting also brings us closer to fixing the following reports:

macro system: Kate still does not have a macro system. A macro can be interpreted as a group of scripts, executed in a sequence (more or less). The vi input mode already supports pretty complex commands, and the code for scripting is all there. It's just a matter of putting this together so it's usable for users.

word count: maybe the word count features can be implemented by a script (too slow?). Problem is, that a script cannot show dialogs etc.

To make scripting an even better experience, we still need to implement binding shortcuts to scripts. Again: any volunteers? :)

Extending Kate with Scripts

2009-10-29T18:41:00.007+01:00

As mentioned in one of my last blogs, there has been quite some work for JavaScript scripting support in trunk recently. So what will Kate 3.4 (KDE 4.4) will bring? This is explained in detail in the sections:

Indentation Scripting
Command Line Scripting
Some Remarks

The scripting allows to extend Kate with lots of little helper functions. All users can add scripts as they wish. The documentation here is copied from the official Kate handbook. So instead of using this blog as reference, please use the handbook later for an up-to-date version. To script something useful, you'll need to know the scripting API. All the available functions are documented in the section Scripting API in the handbook as well. Enough said, here we go:

Extending Kate with Scripts

Since Kate 3.4 in KDE 4.4 the Kate editor component is easily extensible by writing scripts. The scripting language is ECMAScript (widely known as JavaScript). Kate supports two kinds of scripts: indentation and command line scripts.

Indentation Scripts

Indentation scripts - also referred as indenters - automatically indent the source code while typing text. As example, after hitting the return-key code the indentation level often increases.

The following sections describe step by step how to create the skeleton for a simple indenter. As first step, create a new *.js file called e.g. javascript.js in the local home folder $KDEHOME/share/apps/katepart/script.

The Indentation Script Header

The header of the file javascript.js is embedded in a comment and is of the following form

/* kate-script
* name: JavaScript
* author: Example Name 
* license: BSD
* revision: 1
* kate-version: 3.4
* type: indentation
* required-syntax-style: javascript
* indent-languages: javascript
* priority: 0
*
* A line without colon ':' stops header parsing. That is, you can add optional
* text here such as a detailed license.
*/

Each entry is explained in detail now:

kate-script [required]: This text string has to appear in the first line of the *.js file, otherwise Kate skips the script.
name [required]: This is the indenter name that appears in the menu Tools->Indentation and in the configuration dialog.
author [optional]: The author's name and contact information.
license [optional]: Short form of the license, such as BSD or LGPLv3.
revision [required]: The revision of the script. This number should be increased whenever the script is modified.
kate-version [required]: Minimal required Kate version.
type [required]: The type must be “indentation”, otherwise Kate skips this script.
required-syntax-style [optional]: Comma separated list of required syntax highlighting styles. This is important for indenters that rely on specific highlight information in the document. If a required syntax style is specified, the indenter is available only when the appropriate highlighter is active. This prevents “undefined behavior” caused by using the indenter without the expected highlighting schema. For instance, the Ruby indenter makes use of this in the files ruby.js and ruby.xml.
indent-languages [optional]: Comma separated list of syntax styles the indenter can indent correctly, e.g.: c++, java.
priority [optional]: If several indenters are suited for a certain highlighted file, the priority decides which indenter is chosen as default indenter.

Kate reads all pairs of the form “key:value” until it cannot fine a colon anymore. This implies that the header can contain arbitrary text such as a license as shown in the example.

The Indenter Source Code

Having specified the header this section explains how the indentation scripting itself works. The basic skeleton of the body looks like this:

triggerCharacters = "{}/:;";
function indent(line, indentWidth, ch)
{
  // called for each newline (ch == '\n') and all characters specified in
  // the global variable triggerCharacters. When calling Tools->Align
  // the variable ch is empty, i.e. ch == ''.
  //
  // see also: Scripting API
  return -2;
}

The function indent() has three parameters:

line: the line that has to be indented
indentWidth: the indentation width in amount of spaces
ch: either a newline character (ch == '\n'), the trigger character specified in triggerCharacters or empty if the user invoked the action Tools->Align.

The return value of the indent() function specifies how the line will be indented. If the return value is a simple integer number, it is interpreted as follows:

return value -2: do nothing
return value -1: keep indentation (searches for previous non-blank line)
return value 0: numbers >= 0 specify the indentation depth in spaces

Alternatively, an array of two elements can be returned:

return [ indent, align ];

In this case, the first element is the indentation depth like above with the same meaning of the special values. However, the second element is an absolute value representing a column for “alignment”. If this value is higher than the indent value, the difference represents a number of spaces to be added after the indentation of the first parameter. Otherwise, the second number is ignored. Using tabs and spaces for indentation is often referred to as “mixed mode”.

Consider the following example: Assume using tabs to indent, and tab width is set to 4. Here, <tab> represents a tab and '.' a space:

1: <tab><tab>foobar("hello",
2: <tab><tab>......."world");

When indenting line 2, the indent() function returns [8, 15]. As result, two tabs are inserted to indent to column 8, and 7 spaces are added to align the second parameter under the first, so that it stays aligned if the file is viewed with a different tab width.

A default KDE installation ships Kate with several indenters. The corresponding JavaScript source code can be found in $KDRDIR/share/apps/katepart/script.

Developing an indenter requires to reload the scripts to see whether the changes behave appropriately. Instead of restarting the application, simply switch to the command line and invoke the command reload-scripts.

If you develop useful scripts please consider contributing to the Kate Project by contacting the mailing list.

Command Line Scripts

As it is hard to satisfy everyone's needs, Kate supports little helper tools for quick text manipulation through the built-in command line. For instance, the command sort is implemented as script. This section explains how to create *.js files to extend Kate with arbitrary helper scripts.

Command line scripts are located in the save folder as indentation scripts. So as first step, create a new *.js file called myutils.js in the local home folder $KDEHOME/share/apps/katepart/script.

The Command Line Script Header

The header of each command line script is embedded in a comment and is of the following form

/* kate-script
* author: Example Name 
* license: BSD
* revision: 1
* kate-version: 3.4
* type: commands
* functions: sort, format-paragraph
*
* A line without colon ':' stops header parsing. That is, you can add optional
* text here such as a detailed license.
*/

Each entry is explained in detail now:

kate-script [required]: This text string has to appear in the first line of the *.js file, otherwise Kate skips the script.
author [optional]: The author's name and contact information.
license [optional]: Short form of the license, such as BSD or LGPLv3.
revision [required]: The revision of the script. This number should be increased whenever the script is modified.
kate-version [required]: Minimal required Kate version.
type [required]: The type must be 'commands', otherwise Kate skips this script.
functions [required]: Comma separated list of commands in the script.

Kate reads all pairs of the form “key:value” until it cannot fine a colon anymore. This implies that the header can contain arbitrary text such as a license as shown in the example. The value of the key functions is a comma separated list of command line commands. This means a single script contains an arbitrary amount of command line commands. Each function is available through Kate's built-in command line.

The Script Source Code

All functions specified in the header have to be implemented in the script. For instance, the script file from the example above needs to implement the two functions sort and format-paragraph. All functions have the following syntax:

function (arg1, arg2, ...)
{
  // ... implementation, see also: Scripting API
}

Arguments in the command line are passed to the function as arg1, arg2, etc. In order to provide documentation for each command, simply implement the 'help' function as follows:

function help(cmd)
{
  if (cmd == "sort") {
      return "Sort the selected text.";
  } else if (cmd == "...") {
      // ...
  }
}

Executing help sort in the command line then calls this help function with the argument cmd set to the given command, i.e. cmd == "sort". Kate then presents the returned text as documentation to the user.

Developing a command line script requires to reload the scripts to see whether the changes behave appropriately. Instead of restarting the application, simply switch to the command line and invoke the command reload-scripts.

If you develop useful scripts please consider contributing to the Kate Project by contacting the mailing list.

Final Remarks

Right now, it's not possible to assign shortcuts to command line commands. Thus, there is no way of executing scripted commands with shortcuts. Volunteers wanted!

The command line scripting can be accessed for all KTextEditor users through the KTextEditor::CommandInterface. That is, you can query a specific command and execute it with arbitrary parameters (The parameter cmd contains the command itself including all arguments. Example: cmd = "goto 65").

Kate's command line itself is actually a quite powerful tool. It's a little bit sad that it's rather unknown. If you want to know more, just invoke "View -> Swith to command line" (shortcut: F7) and start typing text. More details are in the Kate handbook as well.

The Kate scripting API can be found here.

Help on TechBase, KDE Community Forums

2009-10-05T22:26:00.003+02:00

From time to time techbase readers ask questions in the associated talk pages, e.g. with regard to bugs in the tutorials. Usually, they get no reply. This is mainly because noone gets even noticed about this. I've added a link to the KDE Community Forum now on top of each techbase page (MediaWiki:sidenotice). Maybe this helps that developers new to KDE get more help. A little...

News from the Holy Kate Land

2009-09-18T00:36:00.004+02:00

Since we now all know that Kate is holy (thanks to rms. By accident, he obviously confused Kate with emacs, though) let's have a look at what's going on. In the last months Kate development is quite active, so here is a quick update:

new: on-the-fly spell checking thanks to Michel Ludwig. Highlights include e.g. spell checking in comments of source code or latex parts. Also, constructs like sch\"on work in latex.
extended scripting support in the command line, more on that later
more and more mature vi input mode
lots of bug fixing. quite impressive bug squashing by Pascal Létourneau for more than 4 months now
lots of refactoring and code cleanups thanks to Bernhard!
"Find in Files" appears by default again in the tool view,
"File Browser" uses UrlNavigator, huge code cleanup
convenience updates of syntax highlighting
delayed highlighting of code folding ranges to prevent flickering on mouse move
new command line commands: 'toggle-header' in the Open Header plugin. 'grep' and 'find-in-files'
haskell and lilypond indenter
much, much more, see commits for details.

Thanks to all contributors involved in Kate development. Keep it up :)

Followup on Kate's on-the-fly spellchecking

2009-07-08T12:09:00.003+02:00

As there was a lot of feedback in the last blog, I'll answer some of the questions here.

> Where can I get this patch?
The relevant subversion revisions are r992778, r992779, r992780, r992784.

> Will it be available in 4.3, or only in 4.4?
As KDE 4.3 will be released end of the month, this feature will be available in KDE 4.4 and not earlier.

> Please, please tell me that it's powered by Sonnet, one of the most awaited KDE4 pillar by me...
Yes, it uses Sonnet :)
The old spellcheck dialog however still uses the old spellchecking code without Sonnet. Any volunteers to port this? Also, the on-the-fly spellchecking needs to be more configurable in Kate's config dialog, e.g. selecting the correct language.

> Thanks so much, this was the feature I was mostly longing for in kate.
Yes, it is one of the oldest reports with 1245 votes!

> What languages are supported support?
~~On-the-fly spellchecking works if the specific itemDatas are marked with spellChecking="true" or "1" in the xml highlighting definition files.~~ UPDATE: On-the-fly spellchecking is enabled for all itemDatas by default in the xml highlighting defintion files. To disable it, you have to add spellChecking="false" or "0" to an itemData, e.g. at the end of the cpp.xml file:


<itemDatas>
<itemData name="Normal Text" spellChecking="0" />
...
<itemData name="String" />
<itemData name="String Char" spellChecking="0" />
<itemData name="Comment" />
<itemData name="Symbol" spellChecking="0" />
...
</itemData>

So we have to go through all .xml files and change the relevant parts in the itemDatas section. And that's where we need your help, as we don't know all the languages :) ...and if you want to test this feature, you first have to enable it in Tools > On-the-fly spellchecking.
PS: Is there a better name? Maybe Inline spellchecking? Any linguistic experts around? :)

On-the-fly spellchecking in Kate

2009-07-07T20:51:00.003+02:00

Christoph just added an awesome and long awaited feature: on-the-fly spellchecking. 'Kate's xml highlighting files now have an additional attribute in the itemData section: spellChecking="true/false". C++ comments and strings can be spellchecked now :) Same for all other languages such as Latex. Really big thanks to Michel Ludwig for the patch, good work! Screenshot for latex highlighting:

Kate Test Regression Suite

2009-06-07T13:55:00.004+02:00

This blog is mainly about documenting the process how to run Kate Part's test regression suite and probably not much use for other developers.

Step I: Setup the environment

create the file ~/.testkateregression. The content of this file is a single line pointing to the folder of the checkout of the test regression suite data. For me this is
/home/dh/kde/tests/katetests/regression/
Create the folder where you checkout the suite
mkdir /home/dh/kde/tests
Change to this folder
Checkout the data:
svn co svn://anonsvn.kde.org/home/kde/trunk/tests/katetests

Now all the data is there for testing.

Step II: Run the test suite

go to your build directory of kate (e.g. kdelibs/build/kate/tests/
run the complete suite:
./testkateregression.shell
run specific tests, e.g. for the c indenter:
./testkateregression.shell -t indent/csmart

That's it.

Again System Load Viewer

2009-03-17T20:53:00.002+01:00

It's in kdeplasma-addons now will be part of KDE 4.3. For those who can't wait we have released version 0.6 for KDE 4.2. I encourage developers to get their hands dirty and make it look even better. Another idea is to automatically use the plasma colors so it visually integrates better into the desktop. It's more than good enough though, as it has all the features of KDE3's System Monitor and some more (like support for showing all CPUs' usage). Have fun :)

Creating a Plugin System

2009-02-27T12:14:00.004+01:00

On techbase we have a tutorial about extending your application with a plugin system. However, it's unfinished and some people need it as you can see on the talk page. So if you feel like passing your knowledge on, please fill in the missing sections to complete this tutorial. Just make sure to keep it as simple as possible, of course you can also change what's already there. Btw, we once had such a tutorial for KDE3, maybe you can copy some text from there. It would be awesome to have it for KDE4 as well :)

Feature Plans for KDE 4.2 / 4.3

2009-01-27T13:23:00.002+01:00

Hi KDE developers: As KDE 4.2 is about to be released you should move all your features that did not make it into the KDE 4.2 release to the KDE 4.3 feature plan. Thanks! :)

Compile Time

2009-01-09T19:50:00.003+01:00

Recompiling kdelibs, kdepimlibs, kdebase, kdesdk, kdeplasma-addons, playground/base/plasma all in all takes about 2h 13min on my t41p (1.7GHz, 1.5GB ram). It's still quite fast imo, but I imagine with today's hardware it's maybe 30 minutes? See below for detailed infos. I'm using mpyne's excellent kdesvn-build scripts to build KDE from trunk. I even believe this should be the default way for building trunk instead of the rough road we propose on techbase right now. Are there any reasons not to use kdesvn-build?


Building kdelibs (1/6)
       Preparing build system for kdelibs.
       Running cmake...
       Compiling, attempt 1...
       Build succeeded after 44 minutes, and 56 seconds.
       Installing kdelibs.
       Overall time for kdelibs was 48 minutes, and 49 seconds.

Building kdepimlibs (2/6)
       Preparing build system for kdepimlibs.
       Running cmake...
       Compiling, attempt 1...
       Build succeeded after 7 minutes, and 53 seconds.
       Installing kdepimlibs.
       Overall time for kdepimlibs was 8 minutes, and 14 seconds.

Building kdebase (3/6)
       Preparing build system for kdebase.
       Running cmake...
       Compiling, attempt 1...
       Build succeeded after 52 minutes, and 35 seconds.
       Installing kdebase.
       Overall time for kdebase was 57 minutes, and 44 seconds.

Building kdesdk (4/6) # note: several subdirs commented out
       Preparing build system for kdesdk.
       Running cmake...
       Compiling, attempt 1...
       Build succeeded after 8 minutes, and 26 seconds.
       Installing kdesdk.
       Overall time for kdesdk was 8 minutes, and 45 seconds.

Building kdeplasma-addons (5/6)
       Preparing build system for kdeplasma-addons.
       Running cmake...
       Compiling, attempt 1...
       Build succeeded after 6 minutes, and 15 seconds.
       Installing kdeplasma-addons.
       Overall time for kdeplasma-addons was 6 minutes, and 24 seconds.

Building plasma (6/6) # this is: playground/base/plasma
       Preparing build system for plasma.
       Running cmake...
       Compiling, attempt 1...
       Build succeeded after 3 minutes, and 25 seconds.
       Installing plasma.
       Overall time for plasma was 3 minutes, and 35 seconds.

Quickie: Faster compilation with cmake

2009-01-04T15:05:00.005+01:00

It happens again and again that developers complain about cmake being too slow when compiling after a quick change. The solution is to use

make $target/fast
make install/fast

This way, cmake skips the dependency checking. As example, whenever I change code in kdelibs/kate, I type make katepart/fast and make install/fast.

System Load Viewer

2009-01-02T17:28:00.006+01:00

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

Kate Internals: The Undo/Redo System

2008-11-14T16:10:00.003+01:00

The Kate Editor Component (also called KatePart) has its own undo/redo system. It did not change much since KDE2 and basically it is very simple. Meanwhile there are classes for undo/redo support in Qt as well. In fact both systems are very similar. Let's focus on KatePart's system for now.

Text Operations

First we have to take a look at what actions need to be saved. In KatePart this basically comes down to

insert text or line
remove text or line
selection changes
(and a few others like wrapping a line)

When typing text, each keystroke inserts a character. This is exactly one undo/redo item. As example, typing a character 'x' creates a new undo item:

the content is 'x'
the type is 'insert text'

Undo in this case means 'remove x'. Redo means 'insert x (again)'. The undo/redo history is just a list (more like a stack to be precise) of simple edit actions.

KateUndo Items

In KatePart, an undo item is represented by the class KateUndo:

class KateUndo {
 public:
   KateUndo (KateUndoGroup::UndoType type, uint line,
             uint col, uint len, const QString &text);
   ~KateUndo ();

   bool merge(KateUndo* u);

   void undo (KateDocument *doc);
   void redo (KateDocument *doc);

   inline KateUndoGroup::UndoType type() const;

   inline uint line () const;
   inline uint col () const;
   inline uint len() const;

   inline const QString& text() const { return m_text; }
};

Item Merging

Note the function KateUndo::merge(KateUndo* u); This functions merges two undo items of the same type if possible. For instance, typing 'hello world' inserts one undo item for every character, i.e. 11 undo items of type 'insert text'. Kate merges those 11 items into only 1 item with the string 'hello world'. Merging leads to less KateUndo items (less memory) and faster undo/redo replaying.

Item Grouping

What's still missing is the possibility to group several undo items together. Imagine you have selected the text 'hello world' and paste the text 'cheers' from the clipboard. What happens is this

remove selected text
insert text from clipboard

So there are two undo items of different type. They cannot be merged into only one KateUndo item. Though, we want to support undoing both items in one go, that's why we add several undo items into undo groups. In KatePart, this is done by the class KateUndoGroup:

class KateUndoGroup
{
  public:
    explicit KateUndoGroup (KateDocument *doc);
    ~KateUndoGroup ();

    void undo ();
    void redo ();

    enum UndoType { ... };

    void addItem (KateUndoGroup::UndoType type, uint line, uint col, uint len, const QString &text);

    void setUndoSelection (const KTextEditor::Range &selection);
    void setRedoSelection (const KTextEditor::Range &selection);

    void setUndoCursor(const KTextEditor::Cursor &cursor);
    void setRedoCursor(const KTextEditor::Cursor &cursor);

    bool merge(KateUndoGroup* newGroup,bool complex);

    void safePoint (bool safePoint=true);
};

Every KateUndo item belongs to one KateUndoGroup. A KateUndoGroup can have an arbitrary count of KateUndo items. In the example above we want to group 'remove selected text' and 'insert text' together. Grouping can be explicitely done in the code as follows (simplified version):

void KateDocument::paste ( KateView* view, QClipboard::Mode mode )
{
  QString s = QApplication::clipboard()->text(mode);

  editStart();
    view->removeSelectedText();
    insertText(pos, s, view->blockSelectionMode());
  editEnd();
}

Grouping: editStart()/editEnd()

The call of editStart() tells the document that an edit operation is running. All text operations are added to the current KateUndoGroup, until editEnd() is called. editStart() and editEnd() do reference counting, i.e. editStart() can be called nested as long as for each call of editStart() there is (finally) a call of editEnd().

Grouping: Cursors and Selections

Undoing the paste-action above should restore the selection if there was one previously. Redo (i.e. paste again) should remove the selection again. So there are two different types of selections: one before the undo group, and one after. That's why each undo group has the functions setUndoSelection() and setRedoSelection(). The same applies for the cursor position: We have to store two different cursor positions, one for undo and one for redo.
For instance, imagine we removed the text 'world'. Undo (i.e. insert 'hello') should set the cursor position to the end of 'hello'. Redo (i.e. remove 'hello') should set the cursor position to the start of it.

Luckily a programmer does not have to set the undo/redo cursor positions and text selections manually. undoStart() is called the first time editStart() is called. The closing editEnd() finally calls undoEnd(). So undoStart() sets the undo cursor position and undo text selection, while undoEnd() sets the redo cursor position and redo text selection.

Group Merging

The careful reader might have noticed KateUndoGroup::merge(). So merging of two groups is also supported. Whether text operations should be merged into an existing undo group can be controlled with KateDocument::setUndoDontMerge(). Pasting text for example set's this flag.

Undo and Redo

Every document in KatePart has two lists: An undo list, and a redo list. Suppose we have 10 KateUndoGroups in the undo list and the user invokes undo 4 times. Then the undo list only contains 6 items and the redo list 4. Now it is also possible to redo. However, typing text clears the redo list.

Document Modified Flag

KateDocument::updateModifed() is called to update the modified flag of a file. This update also relies on the current active undo group. Saving the file saves a pointer to the current undo group, and later we simply can check whether the current undo group is the active one. Pretty simple mechanism. However, there right now seems to be a bug you can reproduce as follows:

save doc [not modified]
type a character [modified]
undo [not modified]
type a character [modified]
undo [still modified]

Step 5 is incorrect, as the document is not modified here. Maybe now you have enough knowledge to fix this. Any takers? :)

Akademy 08: Kate Flashback

2008-08-14T23:28:00.002+02:00

This Akademy's Kate changes include

fix: drag & drop of text
code completion: only show group header if the group name is not empty
reintroduction of buffer blocks in Kate's document buffer (one buffer contains up to 4096 lines). The blocks build a linked list. Editing a 500 MB file kind of works now again. It's still rather slow, though.
more speedup in Kate's document buffer
Kate is using KEncodingProber instead of KEncodingDetector now
generate internal version of KatePart automatically, so developers don't have to adapt it manually each release
python encoding detection plugin that warns if encoding is not correct while saving
new plugin: Backtrace browser, mainly for developers
find in files: several speed optimizations
find in files: progress indicator while search is active
find in files: redesign of workflow. Search happens with non-modal dialog and results are shown in toolviews.
lots of vi mode changes
lots of bugs closed, mainly old ones
some real bug fixes...
things I forgot

Kate: Fast backtrace navigation

2008-08-12T17:13:00.005+02:00

I've added a new plugin to kdesdk/kate/plugin: a backtrace browser. It's meant for developers and probably of no use for users. What does it do? It shows a backtrace delivered by gdb in a listview in a Kate toolview. Clicking on an item opens the selected file and jumps to the correct line number. It works for backtraces generated on your own machine, but it will also work for backtraces from other people, i.e. with /home/dummy/qt-copy/.../qwidget.cpp will still be found on other machines. For that to work, you have to index the directories where the source code is located.
Sometimes there are several files with the same name, e.g.

trunk/kdegraphics/okular/generators/dvi/config.h
trunk/kdepim/mimelib/mimelib/config.h

To pick the right choice, the plugin picks the last two parts of the url, in this case this would be

dvi/config.h
mimelib/config.h

and then usually finds the correct one. Indexing trunk/KDE and branches/KDE/4.1 of course will lead to a clash, now way to fix it. Maybe I could present a list of valid files to the user and let the user pick the right one. I don't think that's necessary though for now.

How to configure

Enable the plugin: go to Settings > Configure Kate > Application Plugins and enable 'Kate Backtrace Browser'
A config page appeared, so click on it and add the directories containing the source code
Clicking OK will start indexing. It will take some time (the index of kdesupport + kdelibs + kdepimlibs + kdebase + kdesdk + playground/plasma + plasma-addons + kdevplatform + kdegraphics is about 6MB)

When indexing is finished, open the toolview "Backtrace Browser". Now you can load a backtrace from the clipboard (e.g. when you clicked "Copy to Clipboard" in Dr. Konqi) or from a file.

Hope it's useful :)

C++ Template magic

2008-07-06T20:26:00.005+02:00

Now that Johan talked about why the STL simply rocks I have to add a quick note about C++ templates in general, to be precise about template specialization. I've recently written a ring buffer template, something like

template <class T, int TSize>
class RingBuffer
{
public:
  RingBuffer();
  // ...
  void append(int count, T* first);
private:
  std::vector<T> buffer;
  int start;
  int end;
};

template <class T, int TSize>
RingBuffer<T,TSize>::RingBuffer()
{
  buffer.resize(TSize);
  start = 0;
  end = 0;
}

template <class T, int TSize>
void RingBuffer<T,TSize>::append(int count, T* first)
{
  // code omitted: make sure count elements fit, otherwise return
  // now there are two cases: either count elements fit completely,
  // or we have to wrap around at the end of the ring buffer.
  // the case of a wrap around is ignored here, too

  copyHelper(&buffer[start], first, count);
}

Now the function copyHelper looks like this:

template <class T, int TSize>
static inline void copyHelper(T* dest, T* src, int count)
{
  while (count--) {
    *dest++ = *src++;
  }
}

copyHelper simply assigns count elements with the operator=(), as T can also be a class. But in the case of T being e.g. a simple char this code part performs really bad. However, there is a solution: Template specialization. That means, we add another function copyHelper() and the compiler then is clever enough to pick the correct one:

template <>
static inline void copyHelper<char>(char* dest, char* src, int count)
{
  memcpy(dest, src, count);
}

Now the code is really fast in the case of char. In other words, with template specialization we can heavily tune template code in a lot of cases. And ideally, STL implementations do exactly this, don't they? Does Qt use template specialization for its template classes?

"I miss the applet which shows system usage"

2008-05-31T09:48:00.003+02:00

...is one of the comments on Sune's blog. "I won’t call it a a must-have, but I’d love to have it back :D". Well, I call it a must have, that's why I've ported it to KDE4 a week ago:The code is not in svn yet (here is the code for now). I still had issues with correct resizing and believe there was also a bug in the plasma lib when I developed it which seems to be fixed now. I didn't have time for more testing, but finally this has to go in for KDE 4.2 :)
Besides that, I'm not yet content with how the data engine publishs data. The situation is that all system monitor data is extracted in one tick, but I still would like to publish it in three categories: cpu, mem and swap. But if I do so, an applet's dataUpdated() function is called 3 times and that's not what I want. So for now I put the data into the category systemmonitor and named the items cpu-total, cpu-kernel, ..., swap-total, swap-used, mem-total, mem-kernel, mem-cached, ... However the other way of categorization would be better :) Any ideas?

Offline for 3 months

2008-04-22T11:05:00.002+02:00

I don't have internet the next 3 months. Maybe here and there at some point. That means I can not review the techbase changes. Also, I'll be rather silent wrt kate/kwrite.

Do you understand the word HTML?

2008-04-16T11:39:00.004+02:00

During the Kate developer meeting we also thought about simplifying KWrite and how to make the decision whether KWrite should be launched in full featured mode or in a stripped version. ...well, and we found a really funny idea:

Note, that this would even work, the question would be rather annoying, though :) The solution right now is to always start KWrite in a simple mode. Mostly only actions are hidden in the menus (@distributors: kdelibs/kate/data/katepartsimpleui.rc), but you can also change c++ code at Kate part level, as there are some functions:

bool KateDocument::simpleMode() (kate part internal), and
bool KTextEditor::Editor::simpleMode() (along with setSimpleMode())

This way config dialogs can be adapted depending on the mode as well. Ah, and if you want the normal mode back, go into the KWrite settings and enable [x] Enable Developer Mode. Then restart KWrite.

PS: Tackat, we came up with this image before our phone call. That's why it was really funny when you said HTML is something that should not be removed. hehe... :)

Kate Meeting: Day 1 and 2

2008-04-15T15:29:00.008+02:00

The Kate Developer Meeting was a productive weekend and once more shows how important the developer sprints are. The summary will be on the dot shortly. Work already started on several topics. As everyone want screenshots, here we go: The new annotation interface available now in KTextEditor can be use to e.g. show svn annotations directly in kate:
basysKom's coffee maching is simply the best: It can do everything, you just have to press the right key combos:

Kate Meeting: Day 0

2008-04-11T18:20:00.004+02:00

Finally it all begins: Anders and Joseph arrived at basysKom and we've started to discuss some things we want to do for KDE 4.1. Later, we are going to meet with the rest of the attendees in a restaurant to get to know each other. The official start of the meeting is tomorrow morning. If you are interested in contributing to Kate, just join #kate on irc.kde.org. I'm looking forward to the next two days :)

How to compile and run KDE4

2008-03-19T20:49:00.003+01:00

...or rather how to setup a KDE4 development environment. There already is a howto on techbase, but I'm using my own scripts since years, and they work just fine. I've made them public in my user space on techbase: User:Dhaumann/Compiling KDE4. The howto is very short but complete. It does not have any troubleshooting sections. This is intentional: If you have any errors, fix them and rerun the scripts. Happy compiling :)

Feature Plan on TechBase

2008-01-30T23:26:00.000+01:00

The Planned Features list is up and running again. It just needs to be filled. If you are a KDE developer you should consider to add your planned features to the list :) There are three templates you can use:

{{FeatureDone|project|description|email-address|first-name name}}
{{FeatureInProgress|project|description|email-address|first-name name}}
{{FeatureTodo|project|description|email-address|first-name name}}

Another todo-item now is to merge the old feature lists into techbase.

Growing articles on TechBase

2008-01-28T23:02:00.000+01:00

Right now TechBase has content in 19 languages. Sometimes articles grow bigger over time. How to build KDE4 is the prefect example. Here is a list of pages about building KDE4 (not counting translations):

Getting Started/Build/KDE4
Getting Started/Build/KDE4/Arch Linux
Getting Started/Build/KDE4/Ark Linux
Getting Started/Build/KDE4/Cygwin
Getting Started/Build/KDE4/Fedora
Getting Started/Build/KDE4/FreeBSD
Getting Started/Build/KDE4/Gentoo
Getting Started/Build/KDE4/Kubuntu and Debian
Getting Started/Build/KDE4/Mac OS X
Getting Started/Build/KDE4/Mac OS X 10.5 issues
Getting Started/Build/KDE4/Mandriva
Getting Started/Build/KDE4/Prerequisites
Getting Started/Build/KDE4/Troubleshooting
Getting Started/Build/KDE4/Windows
Getting Started/Build/KDE4/Windows/3rd-party libraries
Getting Started/Build/KDE4/Windows/Building DBus
Getting Started/Build/KDE4/Windows/Building KDESupport Libraries
Getting Started/Build/KDE4/Windows/Building Qt 4
Getting Started/Build/KDE4/Windows/Environment
Getting Started/Build/KDE4/Windows/GCC And MinGW
Getting Started/Build/KDE4/Windows/Littlecms.patch
Getting Started/Build/KDE4/Windows/MS Visual Studio
Getting Started/Build/KDE4/Windows/MinGW Build Tips
Getting Started/Build/KDE4/Windows/Windows Vista
Getting Started/Build/KDE4/Windows/additional libraries
Getting Started/Build/KDE4/Windows/emerge
Getting Started/Build/KDE4/kdesvn-build
Getting Started/Build/KDE4/openSUSE
Getting Started/Build/KDE4 Alpha 1
Getting Started/Build/KDE4 Alpha 2

That makes 30 pages. Some thoughts about this. Splitting up articles makes translation more difficult. There are more pages that have to be synced. It can be unclear where to find the information you are looking for. It's messy. What about

1 page »Distribution Specials«, instead of 11 separated pages?
a cleanup instead of a split, if the page grows more and more?
talk pages sometimes fit better?

Agreed, if pages really get long, a meaningful split makes sense. But sometimes it does not!? Thoughts? :)

TechBase: Contributing...

2008-01-27T21:57:00.000+01:00

How you can help to make maintaining TechBase easier:

login before you edit pages. Reviewing an edit of a logged in user is often as easy as "ah, user X, his content is ok anyway, next one..."
do not use the "I-form". Who is 'I'? Noone knows. Especially not years later. Using 'I' in talk pages is perfectly fine. But please avoid it in articles :)

Reviewing TechBase Changes

2008-01-07T21:27:00.000+01:00

KDE's techbase wiki is pretty much alive and I'm especially surprised that the translation system works really well. Of course there is some maintenance work to do and I'm reviewing every change so far.
I was away from Dec. 27th until 4th of January. Unfortunately, the "recent changes" feature allows me to see only the changes from 1st January till today. So if you have the RSS/Atom feed please review the changes from 27th until 31th of December and fix spam/typos/whatever you think needs to be fixed! :)

Encapsulation is not Information Hiding

2007-12-21T13:03:00.000+01:00

As food for thought and in reply to Why Encapsulation is a Good Thing it's interesting to take a closer look. What does encapsulation mean exactly, and what can you do with it? Maybe what you really want is Information Hiding? ...and encapsulation is just a way of possibly achieving it? If you are interested in the details/differences, read the article Encapsulation is not Information Hiding.

To all TechBase Contributors

2007-12-21T12:41:00.000+01:00

I've just added a new page which lists the KDE TechBase contributors. The idea is to have contact data for quick questions as well as build teams for different maintenance tasks. If you are active in the techbase wiki, please add yourself to the list - be it as a reviewer reading the RSS feed, translator or article writer...

Memory Leak Continued

2007-11-22T11:55:00.000+01:00

There was some confusion with regard to my last blog about leaking memory. Suppose the ui_mywidget.h files looks like this:

class Ui_Widget
{
public:
   QGridLayout *gridLayout;
   QGroupBox *groupBox;
   QGridLayout *gridLayout1;
   QListWidget *listWidget;
   QSpacerItem *spacerItem;
   QPushButton *pushButton;

   void setupUi(QWidget *Widget);
   void retranslateUi(QWidget *Widget);
};

Of course, those 6 QObject derived classes are deleted. But the sizeof(Ui_Widget) = 6 * sizeof(void*) = 24 bytes are not deleted. As Ui_Widget is not QObject derived those 24 bytes leak. Confirmed by valgrind.

In a comment to my last blog Paolo suggested to use auto_ptr or scoped_ptr, which is more elegant than an extra wrapper class :)

Memory leak: Ui files and direct approach

2007-11-21T22:38:00.000+01:00

The KDE codebase often uses a forward declaration in the .h-file to speedup compilation. The code often looks like this:

// header file
namespace Ui { class MyWidget; }
class MyDialog : public KDialog {
// ...
private:
Ui::MyWidget *ui;
};

The impl looks like this:

// source file
#include "mydialog.h"
#include "ui_mywidget.h"
MyDialog::MyDialog() : KDialog()
{
QWidget *w = new QWidget(this);
setMainWidget(w);
ui = new Ui::MyWidget(); // allocation
ui->setupUi(w);
// ui->...
}

See the memory leak? You have to call »delete ui;« in the destructor if you use the »direct approach«. Searching in lxr.kde.org shows lots of results, and in some places this delete is missing indeed. Happy fixing :)

Update: The really correct fix is to guard the pointer with an auto_ptr or scoped_ptr. For further details read the comments below. Or use another approach to include your ui-file.

If you do not want to delete it manually, you can for instance use a workaround like this:

// header file
namespace Ui { class MyWidget; }
class MyWidget;
class MyDialog : public KDialog {
// ...
private:
Ui::MyWidget *ui;
};

Source file:

// source file
#include "mydialog.h"
#include "ui_mywidget.h"

class MyWidget : public QWidget, public Ui::MyWidget {
public:
    MyWidget( QWidget * parent = 0 ) : QWidget( parent )
    { setupUi(this); }
};

MyDialog::MyDialog() : KDialog()
{
ui = new MyWidget(this);
setMainWidget(ui);
QWidget *w = new QWidget(this);
setMainWidget(w);
ui = new Ui::MyDialog(); // allocation
ui->setupUi(w);
// ui->...
}

Once in a while...

2007-10-22T11:44:00.000+02:00

...I simply don't get it.
Recently there was this article on linux.com about [...]. Well, did you know that Konqueror can do all this, too, and much more? Launch Konqueror, split the view and you can transfer data right away with EVERY protocol KDE supports. ftp, fish, webdav and a lot other protocols. No need for an extra ftp client... In short, Konqueror is the best - and you can even use it on the Linux desktop.
...now I stumbled over this article on linux.com about [...]. In Konqueror you can do this for ages, too, the concept is called service menus. And it is very mighty and at the same time very simple to extend. And - if you have a look - there are thousands of context menus available, of course with the slight difference that contributors at kde-apps.org don't get 100$ for their work ;)
I wonder why such articles make it to linux.com at all. This is a drop of quality, imo. This is not about KDE vs. Gnome. It's about that articles should be objective and consider several alternatives. The first solution you read about isn't always the Holy Grail. Sorry for the rant.

PS: Maybe ed is the best text editor, I still prefer Kate, though. *blah* :-)

Kate Highlighting Power

2007-09-12T21:23:00.000+02:00

Kate's highlighting capabilities are amazing. If you want you can highlight really complex syntax, without having to hardcode rules in C++. As an example, we'll take a look at how Lua comments can be realized:

--[=[ starts a multiline comment (the '=' chars are optional)
]=] ends the multiline comment
the number of '=' chars in ]=] must match the number of --[=[

That means: When the highlighting processor matches the end of a multiline comment, it has to know how many '=' chars started the comment. Thanks to the concept of dynamic rules and contexts Kate is able to do that. The highlighting file looks like this. First comes the header

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE language SYSTEM "language.dtd" >
<language name="Test" version="1.0" kateversion="2.4" section="Markup" extensions="" mimetype="">
  <highlighting>

Then the body with the contexts. We start in the first context called "Normal Text". When the regular expression --[(=*)[ matches it switches to the context Comment.

    <contexts>
      <context attribute="Normal Text" lineEndContext="#stay" name="Normal">
        <RegExpr attribute="Comment" context="Comment" String="--\[(=*)\[" dynamic="true"/>
      </context>

The part (=*) is now available as %1 in the rule below:

      <context name="Comment" attribute="Comment" lineEndContext="#stay" dynamic="true" >
        <RegExpr attribute="Comment" context="#pop" String="\]%1\]" dynamic="true" />
      </context>
    </contexts>

The last part is the footer:

    <itemDatas>
      <itemData name="Normal Text" defStyleNum="dsNormal" />
      <itemData name="Comment"     defStyleNum="dsComment" />
    </itemDatas>
  </highlighting>
</language>

If you want to know more about Kate's highlighting, have a look at the documentation :) There are also lots of bug reports, so if you want to contribute you can fix them!

PS: As I don't know much about Lua, comments might work differently. That does not really matter, as the example still shows what you can do :)

List of new KDE features

2007-08-29T11:23:00.000+02:00

Hi, our list of KDE features heavily lacks updates :)
So everyone checkout

trunk/www/sites/developer/development-versions

and update kde-features.xml :) At some point we'll enable the techbase extension so the list shows up there as well.

OT: T-Online Software

2007-08-12T10:49:00.001+02:00

I had to install the "T-Online Software 5" recently on a Win98 box. Starting the T-Online setup a message popped up:

You need at least Internet Explorer 5.5. Setup terminated!

Sigh, I found a IE5.5 offline setup. Next try:

You need at least a resolution of 800x600. Setup terminated!

I found the graphics card chip, installed the drivers and switched the resolution. Next try:

The language version of the OS is not German. Setup terminated!

Now that is clearly how software should not work. It seems to be impossible to install the T-Online software. I would install Linux, but it's quite a change for a ~90 years old user :(

Extending Kate by Scripts

2007-07-21T13:29:00.000+02:00

We have seen how scripting basically works for indentation. It's also possible to register commandline functions (The command line is bound to F7 by default, or invoke View > Switch to Command Line). We will consider a small example again: sort the selected text.

/* kate-script
* name: unused
* author: foo bar
* license: LGPL
* version: 1
* kate-version: 3.0
* functions: sorter
*/

function sorter ()
{
    if (view.hasSelection()) {
        var start = view.startOfSelection().line;
        var end = view.endOfSelection().line;

        var text = document.textRange(start, 0, end, document.lineLength(end));

        var lines = text.split("\n");
        lines.sort();
        text = lines.join("\n");

        view.clearSelection();

        document.editBegin();
        document.removeText(start, 0, end, document.lineLength(end));
        document.insertText(start, 0, text);
        document.editEnd();
    }
}

The header line functions: sorter makes Kate Part aware of the function in the script. A list of functions is supported, separated by white spaces. You can use the function by typing 'sorter' in the commandline.
Some todo items:

provide better JavaScript API. For example: document.textRange() takes 4 parameters. It would be more elegant to take one range or two cursors, just like we do in the KTextEditor interfaces in kdelibs/interfaces/ktexteditor
make is possible to bind scripts to shortcuts. This could be done by e.g. binding commandline functions to shortcuts or implementing a vim-like command-mode in Kate's commandline. How to configure the shortcuts is unclear, though.
then, think about replacing the C++ implementations of 'uppercase', 'lowercase', 'capitalize' etc. with scripts
things I forgot...

If you are interested subscribe to kwrite-devel@kde.org and contribute :) We also need indentation scripts, of course!

Kate: More on Indentation Scripting

2007-07-20T19:18:00.001+02:00

My last blog was about the theory of how indentation works by using javascripts. Now we will look at a concrete example: a LISP-style indenter. (LISP indentation is easy, that's why it's a good example).
The rules:

comments starting with ;;; always have indentation 0
comments starting with ;; should be aligned with the next line
comments starting with ; should only appear behind code, so they are simply ignored
every '(' indents and every ')' unindents

lisp.js looks like this:

/** kate-script
* name: LISP
* license: LGPL
* author: foo bar
* version: 1
* kate-version: 3.0
* type: indentation
*/
// indent should be called when ; is pressed
triggerCharacters = ";";
function indent(line, indentWidth, ch)
{
    // special rules: ;;; -> indent 0
    //                ;;  -> align with next line, if possible
    //                ;   -> usually on the same line as code -> ignore
    textLine = document.line(line);
    if (textLine.search(/^\s*;;;/) != -1) {
        return 0;
    } else if (textLine.search(/^\s*;;/) != -1) {
        // try to align with the next line
        nextLine = document.nextNonEmptyLine(line + 1);
        if (nextLine != -1) {
            return document.firstVirtualColumn(nextLine);
        }
    }

    cursor = document.anchor(line, 0, '(');
    if (cursor) {
        return document.toVirtualColumn(cursor.line, cursor.column) + indentWidth;
    } else {
        return 0;
    }
}

The result:

;;; fib : number -> number
(define (fib n)
  (if (< n 2)
    1
    (+ (fib (- n 1)) (fib (- n 2)))))

As this indenter is scripted, everybody can adapt the style to the own needs.

Kate Scripting: Indentation

2007-07-18T13:17:00.000+02:00

Kate Part in KDE4 supports the ECMAScript (JavaScript) language by using kjs. In KDE3 we had several hard-coded indenters in C++, the idea is to let scripts do all the indentation in KDE4.
How does it work? It is similar to vim: You simply create a script in the directory $KDEDIR/share/apps/katepart/jscript. An indentation script has to follow several rules:

it must have a valid script header (the first line must include the string kate-script and indentation scripts must have the type: indentation)
it must define some variables and functions

Whenever the user types a character, the flow in Kate Part works like this

check the indentation script's trigger characters, i.e. whether the script wants to indent code for the typed character
if yes, call the indentation function
the return value of the indentation function is an integer value representing the new indentation depth in spaces.

In the 3rd step there are 2 special cases for the return value:

return value = -1: Kate keeps the indentation, that is it searches for the last non-empty line and uses its indentation for the current line
return value < -1 tells Kate to do nothing

So how does a script look like exactly?
The name does not really matter, so let's call it foobar.js:

/* kate-script
* name: MyLanguage Indenter
* license: LGPL
* author: Foo Bar
* version: 1
* kate-version: 3.0
* type: indentation
*
* optional bla bla here
*/

// specifies the characters which should trigger indent() beside the default '\n'
triggerCharacters = "{}";

// called for the triggerCharacters {} and
function indent(line, indentWidth, typedChar)
{
// do calculations here
// if typedChar is an empty string, the user hit enter/return

// todo: Implement your indentation algorithms here.
return -1; // keep indentation
}

More details on the header:

name [required]: the name will appear in Kate's menus
license [optional]: not visible in gui, but should be specified in js-files. it is always better to have a defined license
author [optional]: name
version [optional]: recommended. an integer
kate-version [required]: the minimum required kate-version (e.g. for api changes)
type [required]: must be set to indentation

The only missing part is the API which Kate Part exports to access the document and the view. Right now, there is no API documentation, so you have to look at the code:

kdelibs/kate/jscript/katejscript.cpp search for "@Begin" tags

You will find, that the current document exports functions like

document.fileName()
document.isModified()
document.charAt(line, column)
etc...

The view exports functions like

view.cursorPosition()
view.hasSelection()
view.clearSelection()
...

That's the boring part of this blog. The interesting one is unfortunately shorter: we are looking for contributors who want to write scripts or help in the C++ implementation :)

Luggage continued

2007-07-14T21:39:00.001+02:00

Quick notice: I have my bag back. It was wet inside -- probably for 2 weeks, no wonder it started to get moldy inside, and I'm not sure yet whether I can use some of the clothes. Well done BA & Heathrow.

Deeply impressed...

2007-07-11T20:36:00.000+02:00

Hey, I wasn't aware there was another one who did not get his luggage at all in Glasgow. I traveled from Frankfurt(Germany) to London (Heathrow) and then on to Glasgow. When I arrived, my luggage was missing. British Airways told me it would still be in London but it should arrive the same day and they would bring it to the Euro Hostel - cool :) How naive! Of course it did not arrive... and it didn't arrive the whole week.
The online status always said "Still tracing, check back later". When I flew back I asked at the Glasgow airport again and was told they can not see more than what I see online. When I asked whether they could call London/Heathrow by phone they said in London/Heathrow 20.000 bags are missing so it would be pointless. If the system is so unreliable, why don't they simply close the airport. moo
When I arrived in London I asked again, and a BA-service guy told me he could see that my luggage was being sent to Glasgow by road. By road??? Hell, it takes them 1 hour by plane, so what? And I even told them that I would leave this day. So why to Glasgow at all now?
Well, finally I sat in the plane... which ironically had a delay because it had one bag too much. Hey, that could have been mine... :)
Back in Frankfurt I asked again, and at least this time they were capable of changing the destination address to where I live in Germany. Strange, I told them in Glasgow in the first place, but they seem to be pretty much incapable... :)
So here we go: Back in Germany... in the meanwhile I wondered whether I'd see my bag ever again. Today, almost 2 weeks later, the state incredibly changed to "Received at the airport, delivery in progress". Wow, I'm deeply impressed... really great job. Wait: at which airport? Glasgow? London? Frankfurt? Or somewhere else in the world? *sigh*
So in short: I still don't have my luggage back... :)

Translation of TechBase

2007-06-17T23:55:00.000+02:00

As contributors started to translate articles in TechBase to other languages I wrote a quick howto which explains the translation system. It is pretty easy since danimo simplified it with a nifty template :)

Quickies: classmapper, tb

2007-05-31T13:00:00.000+02:00

api.kde.org got an overhaul, the redirect of the old class mapper does not work yet, so just edit your web shortcuts and change the one for 'kde:' to point to

http://api.kde.org/classmapper.php?class=\{@}
appending &version=3.5 will search in KDE3.5

Thanks to Bram, we have a new article called How to create useful crash reports in our tb. It is mainly aimed at users who fill in bug reports in KDE's bug tracking system.

svn up qt-copy...

2007-03-27T21:15:00.000+02:00

...and only 1 hour, 35 minutes later it was finished! Enough said.
Update (disambiguation): svn via https took the time, not the compiling itself :-)

KDE@CeBIT: first two days

2007-03-18T01:18:00.000+01:00

Carsten was already faster and blogged about day 3@CeBIT - so it's time to talk about the first two days :)
The first two days we had a rather small booth compared to other projects in the LinuxPark (Hall 5): Placed in the corner next to the Debian booth (see photo). However, we managed to attract many interested eyes, and that's after all what's important (see photo).
The CeBIT is very much a business event: many people are wearing suits which is not really surprising as the audience is of course different to for example the LinuxTag. As such they have another background: Sometimes they never even saw KDE. That's good as we could show step by step the power of KDE: the desktop itself (kicker, K-button, desktop), applications like KMail users usually need or Amarok with iPod support.
Sometimes the questions were more detailed, amongst others -- of course -- What will KDE4 look like? This one is very important and we tried to promote the difference between KDE4 and KDE4.0, the very first KDE4 release. In short, KDE4.0 is the first release in the whole KDE4 lifetime. As such will ship new tec hn ol og ies and cleaned up APIs. Many work went into the core of KDE which is not even visible to the user. When KDE4.0 is released applications will first have to use it. It does not make *plop* and we have a full blown KDE4 which can be compared to the thousands of applications available for KDE3.5. Even the KDE4 components itself (like plasma) probably will not contain all the features and be perfect right from the start.
This is even good to some degree: It is perfectly fine if plasma is basically the same as what we know from the KDE3.5 workspace - it's a well and long tested behaviour after all. I think we did a good job with regard to issues like this and the interested parties understood that. We demonstrated KDE4 versions of Kate, Dolphin, KRunner and KSysGuard including the new Oxygen icon theme and the general feedback was positive :)
Besides that, we gave lots of KDE-T-shirts, pins and bags for free (iff they made a small donation). I'm sure I forgot something, but it's a way too late now and I have to be at the decibel hackathon in some hours again *tired* :)

Quickies: D-Bus, TechBase

2007-03-05T11:13:00.000+01:00

~~DBUS~~ D-Bus
techbase.kde.org finally has a name
KDE contributors with an svn account are in the group KDEDevelopers, they additionally have the right to delete pages in techbase... if you are not in this group but have a svn account please let us know (#kde-www)
...todo: they also should be able to protect pages so that they are only editable for users in the KDEDevelopers group
techbase uses subpages - please avoid adding toplevel pages :)

Developer Wiki Structure

2007-01-07T22:24:00.000+01:00

The last friday we had 20 people on IRC in #kde-www, that is a lot compared to the 2-5 people usually sticking around there. Some of those 20 are quite active in the techbase wiki so that we have a constant flow of commits. However, there is still a lot of work to do: Migrating tutorials, architecture pages, and more. As you probably know MediaWiki is usually a flat wiki, that is all pages are usually placed in the top. For instance, this is how Wikipedia works. On KDE's techbase wiki we wanted to have a structure even in the URL if possible. It turned out we were lucky because MediaWiki has a features called sub-pages. In short, a sub-page is something like a parent-child relation (like a sub-folder), and the benefits for us are

they automatically provide us with a hierarchy which is reflected in the URL itself
automatically generated backlinks provide easy navigation

For further information, read the page about our wiki structure.

API documentation & refactored kdelibs/kdeui

2006-12-27T23:05:00.000+01:00

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

Friday is developer wiki day

2006-12-27T22:44:00.000+01:00

Some time ago we started to migrate our developer.kde.org pages to a mediawiki based solution at techbase.kde.org. In order to give the wiki a big boost we always meet on fridays on irc.kde.org #kde-www. This friday we will continue to migrate content, besides that we want to find a roadmap and a target date at which we can turn off the old developer pages.
To make this friday an even greater success we need as many volunteers as possible joining us. It is also a nice opportunity to get in touch with the KDE community - we are happy about every new face and - believe us - we don't eat anyone :)

God Jul

2006-12-25T22:56:00.000+01:00

I'm back in Germany after my stay in Sweden. All in all, it was an awesome time. I also traveled to the north to a town called Kiruna (indeed starting with a 'K' =) and you probably guess what I found there: snow, lots of snow. To give you an impression here are two images :)That are nice pictures for the current time of year, so God Jul to everyone and KDE :)

developer wiki

2006-12-15T15:26:00.000+01:00

Now it's kind of official: The first blog about our new developer wiki by Aaron. I'm very happy the wiki gets more attention, and in fact this is a very good opportunity to get started with KDE. As Aaron already mentioned we want the wiki to become a first class citizen for KDE related developer resources. The main task right now is to port pages from the "old" developer pages to the new wiki. At the same time we can restructure the pages like moving KDE 2 and KDE 3 related content to own pages etc. As it is a wiki, everyone is welcome to help. If you want to get in touch with us join us in irc (irc.kde.org, #kde-www)!
Some time ago I wrote a small perl script with which you can convert the html code of the old developer pages to wiki syntax. It's not perfect, but speeds up the process of porting a page tremendously :)

KateMDI: sidebar and focus...

2006-11-28T22:45:00.000+01:00

Since KDE 3.5.5 Kate has its own MDI implementation. It is similar to KMDI but ships with a lot less bugs (yes, and features). One thing bothering me is the focus issue: Which sidebar has the focus? If you do not know, you have to have sharp eyes to find out. In KDE4 I just hacked in such a feature (here is the patch). On the screenshot you can see that every sidebar now has an additional pane on the top. Unfocused sidebars have a gray pane (default window background color), a focused sidebar has a blue pane with white text (just like selected text). Which sidebar has focus? - Right, it's the Documents sidebar :) It work's pretty well, so is it worth committing (a cleaner version of) the patch? I initially hoped that QDockWidgets would provide this functionality by default. Similar discussions take place on kde-core-devel as well (about KTabBar & friends)...

Share Kate Highlighting Files

2006-10-12T23:35:00.000+02:00

Thanks to Frank we have a dedicated section for Kate Highlighting files on kde-files.org now. We encourage everyone to publish their .xml files there. The Kate team agreed to add more highlighting files to the official Kate releases, though, as long as they are of general use. For KDE4 we plan to have a section for Kate Indentation scripts, too. But that's content for another blog, which will follow later :)

Kate: More eye-candy

2006-09-29T19:34:00.000+02:00

Two years ago we had the KDE conference in Ludwigsburg, Germany. At that time, Martijn Klingens committed a patch to show trailing spaces in Kate. I just change the visualization a bit, the change is in for KDE4 :) Tabs are marked with a '»' character, and spaces with a dot. On the left you can see the old and on the right the new version; Here is a screenshot:

Hibernate

2006-09-26T21:58:00.000+02:00

I use the suspend2-sources in Gentoo. After upgrading to XOrg7.1 with newest ATI drivers (fglrx, version 8.29.6) hibernate did not work anymore. Suspend-to-disk hanged at the point: "Doing atomic copy".

While searching the web I found a fix: Edit hibernate.conf (or /etc/hibernate/common.conf) and set

ProcSetting extra_pages_allowance 20000

That did the trick :) Tomorrow will be my second attempt to fly to Dublin. So far it looks pretty promising :)

Bad Luck

2006-09-23T00:46:00.000+02:00

As everyone else I wanted to fly to Dublin on friday, too. While packing the day before I noticed I could not find my identity card. To make it short: I was at the airport with a copy and several other papers that (more or less) state my identity, but no luck. There is no way to travel without a valid identity card to Dublin.

So I'll take another plane 5 days later, on wednesday. There is a small chance (maybe 5%) I might be able to come on monday already. Let's see... :)

All in all I'm missing almost all of the highlights, just look into the conference program.

Lesson learned: Start packing 1-2 weeks before. sooooo stupid :(

The Wheel of Time Turns...

2006-09-16T07:53:00.000+02:00

...and this time it turns out that I am going to akademy. Dublin I'm coming, wheee! :)

Moving

2006-08-20T14:14:00.000+02:00

Last week I moved to Skövde in Sweden. It's a middle-sized town (about 50000 inhabitants iirc) in the central of Sweden just between the two big seas. The weather is quite nice still and so far everything looks interesting. I did not see an elk yet, though :)

In order to have internet access I have to go into a shopping mall. This makes KDE development a bit harder for me as I used to be in contact via IRC a lot and use the web as api reference. That's it for now :)

update 2006-08-21: Skövde has about 50000 inhabitants.

Smart End

2006-08-09T12:33:00.000+02:00

Since KDE 3.5.4 Kate Part supports "smart end". Right now it behaves like this when pressing "end":

go to last non-space character
go to the last character (i.e. hit end twice)

I'm writing this blog to get feedback about what's the right/expected behaviour. Is it as described above, or should we first go to the very last character, and to the last non-space only when hitting then end-key twice?

Feedback along with why you prefer solution A or B is welcome!

Kate in KDE 3.5.4

2006-08-02T20:51:00.000+02:00

Finally, KDE 3.5.4 is out! We were able to fix a lot of issues in Kate and the bug curves went noticeably down. Thanks to all contributors for the nice KDE release :)

Kate: Shortcomings of .kateconfig file

2006-07-23T21:02:00.000+02:00

Assume you have a .kateconfig file optimized for C++ code that replaces tabs on save. Now you open a Makefile that contains tabs (due to its strict syntax). If you save the Makefile in kate, the tabs then are replaced which results in a corrupted Makefile.

In other words: The .kateconfig file applies to every file. It lacks mimetype/extension support and thus can lead to unwanted behaviours.

So if you use a .kateconfig file, keep that in mind :) Maybe we should simply use modelines in the h/cpp files for now.

Indentation and Coding Style

2006-07-23T10:56:00.000+02:00

kdelibs will have coding style conventions. In general. this is not a bad idea. Our 45528 slocs in KatePart all use a consistent indent-width of 2 spaces. Changing this does not really make sense - ok, if svn praise -w (sure, we never need svn blame in our code ;) finally works, we can discuss this again.

In other words: How "consistent" will kdelibs get with this new conventions? The interesting part of Zack's mail is

[...]
No exceptions. Either everything or nothing
[...]

While everything would really be cool, in truth it's not possible to achieve, is it? We will have exceptions or rather violations, I'm pretty sure :)

Some developers already start adding katepart modelines to their souce code. For those who don't know yet: You also can simply use a single .kateconfig file, which is the equivalent to emacs dir config files. You just have to make sure to set the search depth for a .kateconfig file to - let's say - 3. Do this in

Settings > Configure Kate... > Open/Save

Kate Project Plugin

2006-07-20T10:24:00.000+02:00

It is not a secret that removing Kate's project manager in KDE 3.5 was not the right thing to do. It seems a lot of people used it and we got many complaints about this decision. That also shows that it is hard go get feedback about what users are really using. If a feature is done well, noone will ever talk about it. This is paradox, as we thought the project manager was not well integrated :) (I still think that)

Ok, let's come to the interesting part: Three developers wrote a new Kate Project Manager Plugin and published an initial release on sourceforge.net and on kde-apps.org. It works quite well already and reading the comments on kde-apps.org gives me the impression that there are more features to come with the next release. -- If you are interested maybe you want to join the project...

PS: I have the secret hope the plugin will be ported to KDE4 using Qt's model/view architecture, so that it has good support for multiple mainwindows :)

Access Keys

2006-07-05T10:55:00.000+02:00

Our beloved konqueror browser supports a nice feature called access keys. To enable the access key mode you simply have to press ctrl. I quite often use ctrl+c/v in forms, and thus happen to trigger actions accidentally all the time. We are lucky though, as you can disable the feature by putting

[Access Keys]
Enabled=false

into your ~/.kde/share/config/khtmlrc

Triple clicks

2006-06-30T12:13:00.000+02:00

Text editors and line edits support the so-called triple clicks according to [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.

Question now is: Should we change it for KDE 4 in Kate Part just to be compliant with the others? As Kate Part is an editor component mainly used for programming, my favourite option is to include it, i.e. to keep the current behavior.

(update) I just stumbled over http://bugs.kde.org/show_bug.cgi?id=91041 =)

[1] http://developer.kde.org/documentation/standards/kde/style/mouse/selection.html

Kate Part in upcoming KDE 3.5.4

2006-06-28T21:03:00.000+02:00

The last week was highly productive for Kate Part, as the following bugs were fixed:

89042 while pressing "del" key kate crashes (crash, bt)
103648 Codefolding Crash - Reproducable
118584 scroll position not upgrading (dynamic word wrap)
119435 kate crash when a file is saved
123315 kwrite/kate crashes randomly after save
124102 changing syntax highlighting when code is folded crashes katepart
127928 kate crashes deleting a block of text
128690 Dynamic word wrap makes text input slow
129853 Horizontal scrollbar and view not synced, if dynamic and static word wrap are off
and some minor issues

That are 6 crash fixes. Kate Part in KDE 3.5.4 will be more stable than ever :) That's especially cool for KDevelop, Quanta+, Kile - well and Kate.
Special thanks to Andreas Kling for initiating the bug squashing sessions! You are like a blackbox: The input is a bug and your output is the fix ;)

Start blogging

2006-06-26T02:29:00.000+02:00

Today I created an account and this is my first blog.

Huzzah.