Today I wrote a file selector in QML. This was not trivial because QML has no standard element for drilling down in a tree model. So I wrote one. A bit of Python was needed to expose the file system to the QML as a data model.

I've played with Bup a bit lately and wanted to write a GUI for it. Normal Qt widgets would do, but when the bup developers asked if it would run on MeeGo, I had a look at QML.

Update: check the comments for a new version.

The Python part of the code is simple and short:

In my previous blog I talked about converting ODF files to PDF files with WebODF. This is a functionality that is generally useful, but is also one that lets OfficeShots compare WebODFs ODF rendering to that of other office suites.

Another useful feature is round-tripping of ODF. Round-tripping is the process of loading an ODF file in a program and subsequently saving it again. It is an ODF to ODF conversion. OfficeShots uses round-tripping to see if an office suite generates valid ODF. In WebODF, the original ODF file is barely modified. The XML contents of the ODF is parsed and serialized in this step. Any bugs in this process would be exposed by roundtripping.

After building, the round-tripping can be performed like this:
qtjsruntime lib/runtime.js roundtripodf.js myfile.odp

The file will be roundtripped in-place, so make sure to make a copy before trying this.

In the next blog entry I'll talk about WebODF on Android, editing ODF or unhosted.org. Please vote in the comments, come to the irc channel #webodf or post bugs or comments.

It is quite common that one wants to send ODF files to people that lack the software to display ODF. One workaround is to convert the ODF to PDF. Most office suites that support ODF can export to PDF. To compare how different office suites do this conversion one can use the website OfficeShots. This website offers the ability to perform this conversion in many office suites at once and to compare the results.

WebODF wants to play with the grown-ups. So I have extended WebODF with the ability to convert from ODF to PDF. Here is a small script that shows how to do this conversion for a file /home/user/file.odt:

# compile WebODF
git clone http://git.gitorious.org/odfkit/webodf.git
mkdir build
cd build
cmake ../webodf
make
cd ../webodf/webodf
# perform a conversion
FILE=/home/user/file.odt
cp "$FILE" .
FILE=`basename "$FILE"`
../../build/programs/qtjsruntime/qtjsruntime --export-pdf render.pdf "odf.html#$FILE"
ls render.pdf

The programming language JavaScript is seeing more and more use. Software written in it can run in many different environments. Not only do web browsers support it, there are quite a few programming environments that can integrate and run JavaScript code. Qt has support for it with the QtScript module. GNOME has JavaScript bindings via gjs. Node.JS is gaining popularity on the server and Java has the Rhino runtime.

Support for the basic language features of JavaScript is good among these runtimes. You can have a look at the list of dialects of JavaScript/ECMAScript to see that "ECMA-262, edition 3" is the most common specification that is implemented. Nevertheless, each of these environments has different facilities for accessing parts of the environment they are running in. Modularizing the code, access to the file system, logging, starting a new execution thread, running unit tests, these are but a few of the use cases for which there is no common solution.

There are few good practices that have helped me to keep my JavaScript code working in multiple runtimes. Most of the code for WebODF, an ODF project written in JavaScript, runs in the popular browsers, in QtScript, in Rhino and in Node.JS.

Abstraction

First of, I have written a small abstraction layer that wraps loading of modules, logging, unit testing and a few other things. This abstraction layer is not very large, it is a single file. The code contains an abstract class with implementations for the different runtimes. Whenever I need to access a runtime-specific funtion, I resort to this class, extending it where needed.

JSLint and Closure Compiler

JavaScript is a dynamic language, there is no compiler. This means that there are no steps required between writing the code and running the code. Code errors can easily slip in to released code. It is therefore very important to do static testing of the code. Two good tools for this are JSLint and the Closure Compiler. JSLint is a JavaScript program that analyzes code for correctness and style. Some features of the JavaScript language do more harm than good and JSLint brings occurrences of these to your attention so you can avoid them. The Closure Compiler can compile a collection of JavaScript files into one smaller file. But that is not why I use it. While 'compiling' the JavaScript, the Closure Compiler performs a number of checks on the code and catches certain problems before the code is actually run.

Unit testing

Running JavaScript on the command line, in a desktop program or on a website are very different. So sharing unit tests across these environments is a bit of work initially. Having good unit tests is invaluable though, so it is an investment you just have to make if you want to stay confident of your code. For WebODF, I have written a small script or web page for each environment in which I want to run the unit tests. So unit tests are written only once but tested in all environments where they are relevant.

An amazing tool for checking how much of your code is covered by unit tests is jscoverage. It can 'instrument' your code. While running the instrumented code, reports are created that show how often each line of JavaScript was run. This makes it easy to find for what parts of your code could benefit most from an additional unit test.

Conclusion

JavaScript is nearly everywhere. But to write JavaScript that can go nearly everywhere too, you need to take portability into account. The best way to do that is to develop for at least three runtimes in parallel.

With Akonadi most operations are running behind the scenes, carried out by background helper processes called Akonadi Agents.

While we do have respective progress monitoring in KMail2, users will eventually take advantage of fact that they are no longer tied to specific applications. At which point they might want to be able to check on the status of these background processes without launching some front end applications.

Back in April, during one of our development sprints, I've created a Plasma DataEngine which provides information about running Akonadi agents.

I was kind of hoping that somebody with actual widget skills would be curious enough to try some Plasma widgets on top of it, alas this didn't happen.

Therefore I sat down today and wrote one myself, using the opportuntiy to also have a first real attempt in doing some KDE<->JavaScript coding.

The code for it more or less looks like this:

layout = new LinearLayout( plasmoid );
layout.orientation = QtVertical;

engine = dataEngine( "akonadiagents" );
agents = engine.sources;

resources = new Array;

addAgent = function( name ) {
  label = new IconWidget();
  label.orientation = QtHorizontal;
  layout.addItem( label );
  resources[ name ] = label;

  engine.connectSource( name, plasmoid );
}

plasmoid.dataUpdated = function( name, data ) {
  label = resources[ name ];

  label.text = data.name;
  label.icon = data.typeIcon;

  label.infoText = data.statusMessage;
  if ( !data.online ) {
    label.enabled = false;
  } else {
    label.enabled = true;
    if ( data.status == 1 ) { // running
      label.infoText = data.statusMessage + " (" + data.progress + "%)";
    }
  }
}

while ( agents.length > 0 ) {
  agent = agents.pop();

  // ideally this would be using the agent type's capabilities, but the DataEngine::Data as returned by
  // DataEngine::query() is not accessible from within JavaScript (or at least nobody on #plasma knew)
  if ( agent.indexOf( "resource" ) != -1 ) {
    addAgent( agent );
  }
}

I am sure this is not very pretty from the point of view of skilled JavaScript users, you are welcome to beat me on that :D

Anyway, screen cast of the Plasmoid in action, as usual on blip.tv

It shows the widget running in plasmoidviewer side by side with Akonadiconsole to demonstrate that the data engine really exposes the same data.
I start with toggling a local VCard file resource between Offline and Online state, which the widget visualizes by disabling/enabling the respective item.

Finally I synchronize all collections of the IMAP resource, showing status and progres reporting.

Aaron, Sandro, moofang, Shantanu and Diego have been hacking up a Plasma storm lately on the Javascript bindings for Plasma and the Plasmate builder tool. Since good code is running code, and running code is a lot easier when somebody else builds it and packages it, I've updated the Plasmate packages in KDE:KDE4:Playground to 0.1alpha2 and have updated the javascript bindings in our KDE SC 4.4.1 packages to include Aaron's latest errata - no need to update yourselves.

So it's even easier to take part in the Plasma Javascript Jam Session competition now.

And while you're at it, how about completing the loop by using our kde-obs-generator to package your plasmoids and make them available on kde-look.org, so others can start to download and improve them directly in Plasmate? Free Software virtuous circle FTW!

I noticed yesterday that at the kde-apps.org page for WMIface, a tool that allowed scripting the window manager used by KDE3 from command line, a comment appeared asking about a version for KDE4. It felt like a good idea to do something as simple as this in the evening as a relaxation, so, after quite some time playing with C++ templates and so on (since I'm a lazy developer and therefore I went with doing some extra work that would save me from doing work), I have to disappoint you. There is no version specifically for KDE4. In order to reduce the dependencies I made it depend on just QtCore and X11 libs, with those few important classes from kdeui copied into the project. No KDE dependency whatsoever. This provides the CLI tool with startup time decent enough for direct usage, and makes it usable on every system, KDE, GNOME, Xfce, whatever.

PS: The possibility of the much more powerful scripting in KWin itself is still there for anybody interested enough to do it.
PPS: Anybody who ignores the kdeui classes for window management and uses this user scripting tool from an application will be tarred, feathered and publicly laughed at. You've been warned.
PPPS: Every decent system, that is - anything that has QtCore and a reasonably wm-spec-compatible window manager.

The World Wide Web Consortium is looking into the feasibility of standardizing desktop widgets. They have done a survey on the widget frameworks available in the market. The frameworks they have surveyed are Konfabulator, Windows Sidebar, Google Desktop Gadgets, Opera Widgets, Mac OSX Dashboard, Web-Runtime by Nokia, and Joost Widgets.

The survey was performed in the first quarter of 2008 and frameworks were chosen because of their perceived prevalence in the market place. Since KDE 4 was only just released and not available as a stable option for any distribution, W3C cannot be blamed for leaving out Plasma.

"The purpose of this document is to provide a holistic overview of the widget space" is what the survey says. It compares the different offerings and tries to unify the nomenclature for the different gadgets/widgets/plasmoids.

In addition to this document, W3C has published a document that "lists the design goals and requirements that a specification would need to address in order to standardize various aspects of widgets." So W3C is trying to see if they can pen down a standard that captures the features of the current products. If they can achieve this goal, it will be easier for developers to write widgets.

This document is a nice documentation and comparison of the frameworks that are out there now. There is a table that lists the media capabilities of the different frameworks. It would be interesting to see how Plasma stacks up.

The W3C might consider including Plasma properties in their documentation if the Plasma developers contacted them. Even without adding Plasma explicitly, such an emerging standard would help Plasma developers in supporting all the different widget formats out there.

The document also describes the differences from Java Applets. The authors claim that programming in Java is daunting and that using HTML, CSS and JavaScript is much easier. That is a controversial statement considering that all programs implement HTML, CSS and JavaScript differently whilst all Java implementations (with the same version number) are the same.

After a day's work at the Plasma sprint, there's already quite a lot of news
to report. After a lot of trawling through log files, I was able to fix the
problem that was preventing the Plasma binding plugin from loading. In the end
it was something simple (as usual) namely that the method that allows the
plugin to load was not being compiled into the module since it was missing
from the generated .pri file. Once this was fixed, it was simply a matter of
changing the name of the extension we load from 'qt.plasma' to
'org.kde.plasma' to match a fix in the generator and we had a successfully
loading set of bindings.

Lots of thanks are due to Kent Hansen of Troll Tech
for this - not only did he write the binding generator and the type system for
the Qt bindings, he also fixed up the one for plasma. Oh, and if that wasn't
enough he's even figured out the bug that has been preventing the generated
code from having anti-aliasing enabled.

In order to test that these bindings worked properly, I wanted to create a
small demo that exercised the script engine code, the Qt bindings and the
plasma bindings in the same plasmoid. My initial attempt worked ok, but didn't
look very good (though it had the advantage of requiring only a tiny amount of
code). Instead, I'll show a slightly more complex example that looks prettier.

Obviously, you can't see the animation in the screenshot, but this shows four
squares spinning around a common axis at different speeds and changing
colour. Ok, it's not the best piece of graphic design you've ever seen but it
does illustrate that the crucial facilities are in place.

In addition to the coding, we also spent some time today going over the
results Seele obtained from her interviews with some of the developers. We
were looking at the user populations we are currently supporting well, but
more importantly at those that we could potentially encourage to adopt KDE and
Plasma to consider how we can improve the facilities we offer for them
too. Before anyone gets hot under the collar, this doesn't mean ripping out
functionality to 'dumb down' the interface, in fact a lot of the suggestions
were more about how we can improve the interface consistency.

Following this discussion we did some more coding and also broke down into
smaller groups so we could continue to plan for our inevitable world
domination.