This week is the last of the "active coding" period of the Google Summer of Code. On Monday 11, students should stop implementing features and start documenting things, fixing the remaining bugs and ensure that everything is working.

I don't have a huge list of new features to present this week because I had to fight a very nasty bug (and it is still not entirely resolved), but here is nevertheless an addition to the QML/Javascript language support plugin for KDevelop that may be quite useful to a lot of people: support for the Javascript DOM.

The Document Object Model

Last week, I added support for Node.js modules. I did that because several users of the QML/JS plugin told me that they regularly work on Node.js code. This week, despite a bug that makes the unit tests fail (but not the real-world KDevelop), I decided to add support for the Document Object Model of Javascript, so that web developers have their scripts fully supported by KDevelop. As libraries like jQuery also rely on the DOM, having it supported is a good thing.

The DOM is really huge and contains hundreds (if not thousands) of classes. Each HTML element or CSS property has its own class, and there are even classes for things like cookie handling, message passing between web pages, XmlHttpRequest, etc.

I was not very fond of the idea of writing Javascript description files for all these classes. Luckily, I received an unexpected help here: Webkit (the web engine) also has to support these classes, and instead of implementing them directly in Javascript on C++, it ships files having a .idl extension. These files describe the API of the different classes and look like this:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

module window {
    interface [ ...ignored... ] DOMWindow {
        attribute [Replaceable] BarInfo locationbar;
        attribute [Replaceable] BarInfo menubar;
        attribute [Replaceable] BarInfo personalbar;
        attribute [Replaceable] BarInfo scrollbars;
        attribute [Replaceable] BarInfo statusbar;

        DOMSelection getSelection();

        [Custom] DOMWindow open(in DOMString url,
                                in DOMString name,
                                in [Optional] DOMString options);
    }
}

The statements between brackets are hints for the Javascript binding generator and can be ignored. What is interesting in those files is that the attributes, methods and arguments are all named and typed. This means that no information is missing! I just had to write a Python script that parses one of these files and produces a .js equivalent, and I was able to add support for all the DOM.

This morning, I've pushed a big commit to the kde:kdev-qmljs repository. It adds more than 10000 lines of .idl and .js files (I ship the IDL files so that looking at them and possibly modifying them is easier, but their real origin is Webkit). The Javascript file describing the DOM is approximately 4000 lines long and takes a bit more than two seconds to parse. In order to keep it to a reasonable size, I skipped the Canvas classes, the HTML classes (having Element is enough, no need to have HTMLLink, HTMLParagraph, HTMLSpan, etc), the File classes (web storage), the XML parser classes and several other ones. They are rarely used and would have made the description file far too big and too slow to parse. I can still add these classes if many users need them, though.

Here are now some screenshots:

Creating a DOM element.

Code-completion for DOM classes.

Code-completion for global variables and functions (that are in fact members of "window", yes, "window.alert()" works in JS).

Finishing touches and wish-lists

The DOM was the last big feature planned for the QML/JS plugin. In fact, I'm very happy to have been able to go this far in the project. My original GSoC proposal was entirely oriented towards QML, with only basic support for Javascript (just enough for Javascript snippets to be usable in QML files).

I've still some bugs to fight and some things to improve. For instance, having "class HTMLElement inherit Element" displayed in the navigation widget instead of "function HTMLElement()" could be a nice addition. Allowing the user to add include paths (for Node.js and QML modules) could also be great, because some QML modules are not installed at the same place as the others.

But what I would really like to do is to implement what daily QML developers may want. I have posted a message on the plasma-devel mailing list asking which features Plasma developers (regular QML users) may want. I've already got some hints, but don't hesitate to tell me what you would like to have implemented in kdev-qmljs. I will also be in Randa, and while most of my time will be dedicated to porting the QML/JS plugin to KF5, I will also try to listen to the wishes of everyone present.