Category Archives: Common

Plasma Active, the stage is yours

Thanks a lot to Intel for passing around the ExoPC at the AppUp workshop yesterday. Its kind of nice hardware to start developing for Intel based tablets, whereas for normal use, the battery life and weight is kind of problematic. I really like the idea to be able to write nice and shiny Qt applications which run both on MeeGo and Windows and the AppUp store is really open in respect to allowing distribute open source software.

But…

After playing a bit with it last night (it runs some preloaded MeeGo image with the table UX from Intel), for me it is clear, Plasma Active is here the way to go.

The pre-installed tablet UX is really, lets say, interesting. Already the startup is kind of weired: your X comes up, you see the ugly X11 default cursor and then, after some flashing around small windows, the UX is there. Some triangle at the right let you go to the main screen. But no, you not drag at it, you need to click. If you then start using the UX, you get kind of scared away by either rendering artefacts, lags or really interesting design concepts (to go back to main screen from an application, you need to touch the left/right upper corner, without any visual hints, kind of confusing, I am dumb, I just rebooted several times to come back to the main screen). In addition, at least this MeeGo version doesn’t seem to be able to handle multi-touch, which really kills off any fun on using, you can’t even zoom your pictures (or just the applications don’t support it, in any case compared to this, Nokia’s N9 has really a powerful UI).

The good thing is: You need not to use the default MeeGo installation. The hardware is really open in the sense that driver support is no issue (the nice thing with mostly standard Intel hardware). So, go fetch your most recent and flashy Plasma Active image and have fun.

Plasma Active has really a big chance here! Given the current state of the “default” MeeGo table UX, Plasma Active is BIG step into the right direction. I hope the Plasma and KWin developers keep on improving this.

A shiny Wayland based KWin + Plasma combo might really be a game changer here (presentation about KWin + Wayland).

I hope more people and perhaps companies (like basysKom, which did a real nice job with the above shown Contour shell for Plasma Active, short article here) step up and start pushing this effort even more.

Therefore: Thanks again to Intel, I guess they will see more MeeGo apps around soon and lets hope that Plasma Active will get a nice boost, too. Intel will benefit from a better UX in any case!

Maintainer Needed: Kate – External Tools Plugin

The “External Tools” plugin is one of the oldest plugins of Kate. A big hug to Anders Lund for writing it years ago, a lot of people enjoyed using it.

It allows the user to specify own commands (aka snippets of shell programs) to be executed with the text of the current document or the current file.

Basic stuff you can do with it:

  • Create you a little command that shows an Git/SVN/… diff of current file
  • Sort the file with command line sort program (or more advanced scripts)
  • Pipe the text of the document into your most loved perl script

Unfortunately there is no maintainer for it at the moment. Therefore it will be disabled for KDE 4.8, as a lot of bugs sneaked into it during the late 3.x and whole 4.x life-cycle. (Mostly because of bad porting done by me and others and no time to fixup any real bugs)

If you want to step up for maintainer ship, please contact me (cullmann@kde.org) or kwrite-devel@kde.org.

Thanks a lot in advance ;P

Btw., some of the bugs (now no longer valid but interesting for future maintainers):

  • https://bugs.kde.org/show_bug.cgi?id=117946
  • https://bugs.kde.org/show_bug.cgi?id=181528
  • https://bugs.kde.org/show_bug.cgi?id=261210
  • https://bugs.kde.org/show_bug.cgi?id=97569
  • https://bugs.kde.org/show_bug.cgi?id=110485
  • https://bugs.kde.org/show_bug.cgi?id=153963

GSoC – Kate Code Folding (some more details about folding)

Hi!

Yesterday I received a comment on my previous blog post that it would be nice to give some more technical details about the folding.

Initially, this was a comment response, but because it proved to be pretty interesting and more of you read the articles than the comments, I decided to post it as an article :)

Here are some details that you could find interesting:

Kate’s folding is based on a real / virtual line system. All the folded block’s lines have the same virtual line (they are literally folded under the first block’s line).
But how are these blocks defined?
Kate uses the file extension to determine what defines a block (special characters like “{“ or “}”, text alignment and so on). Kate’s highlight sends some info about these to Kate’s code folding. Let’s call them “document’s anchors”. This info is rudimentary. It is mentioned only the type of anchor (encoded as a number greater than 0 if it is a start anchor and lower than 0 if it is an end anchor) and its position in the document (real position). I use this info to build the “folding nodes” (I will detail them later) and to keep their position updated as well. So, here we have the first data structure: the “line mapping”. Line mapping is a QMap <line_number, QVector > and contains an entry for each document line that has at least one anchor I was talking about earlier. If this structure is updated correctly, then I am sure that all the folding nodes have their position set correctly and I don’t need to worry about that.

Now, I know where the document anchors are. But that isn’t enough – I need to form folding blocks with them.
I found two solutions for this “matching” problem:
1. Use a stack and rebuild (using the line mapping) the folding tree from scratch every time something is changing. The algorithm was very simple (parenthesis matching problem), but I found it pretty ugly (and slow) to rebuild the entire tree so often. I didn’t discard the idea either. The algorithm was perfect to be used as a term of comparison for the other algorithm.
2. Use a tree algorithm that changes itself dynamically. This was the solution I chose. I developed an entire project (see my previous posts) that helped me improve this algorithm and I believe it works pretty well. :)
The folding tree is made of folding nodes. These nodes contain info about their position (actually the document’s anchor that they represent), parent, type, matching node – all the info needed to define the folding blocks. If this tree is correct, then the blocks are defined correctly.

If you have the folding blocks defined, then you can fold them. To do this I use the third (and the last) data structures: a QList with the folded nodes. You might ask why we needed another(!) data structure. There are 3 methods that are called very, very often: getRealLine (virtualLine), getVirtualLine(realLine) and getHiddenLines(). Search through all the folding nodes (using the folding tree or the line mapping) is slow. Imagine if we do this search for every line of the document (actually there are about 2 or 3 calls per line every time something changes in the document!). I have also made one more improvement here: if a folded block contains another folded block, then the inner folded block is removed from this structure (it won’t help us discover the virtual or real lines).

Basically, these 3 methods are the code folding – the real / virtual line system I was talking about in the beginning. But.. there is a long way and lot of work to be able to answer these 3 questions fast and correctly. :)