This week is going to be a bit busy as I have an exam tomorrow, on Thursday and then next Monday. I still have had some time to implement cool new features for the QML/JS language support plugin of KDevelop. This blog post will not contain any screenshot because these features are not very visible, but are interesting nevertheless.
Automatic import of all the files of the current directory
myapp.js may refer to
jquery.js, but nothing in the code gives this information.
There is a small technical difficulty here, though: if every file imports all the others, we get circular dependencies (A imports B and C, but B imports A and C, thus A can see itself by the way of B). The solution that I used is to “copy” the declarations of every file into the others instead of importing them. This way, A doesn’t import anything but contains the declarations of B, C, etc. B does the same, but uses the version of A without the declarations of B, C, etc copied. This way, A cannot see itself by the way of B, and B cannot see itself by the way of A.
Copying declarations? And what happends if a declaration changes? What about memory usage? Those are valid questions, and I draw your attention to the fact that I’ve put quotes around “copy” :-). The plugin does not copy the top-level declarations of each other file, it creates alias declarations for them. An alias declaration is a declaration that points to another. For instance, “myVariable refers to myVariable in B.js”. This way, if B is modified and the type of myVariable changes, A will immediately see the change. This is also a bit lighter that copying the declarations.
This feature also refers to import statements. When the user imports a QML module, a version has to be given (as in
import QtQuick 2.1). This version was not used until now, but is now understood by the QML/JS plugin. If you import QtQuick 2.0, you will not see the components that appeared in QtQuick 2.1, 2.2 and 2.3. More importantly, importing QtQuick will not import a mixture between QtQuick 1.0 (Qt4) and QtQuick 2.0 (Qt5). This solves the problem that was visible in my previous blog posts: there are no longer dozens of duplicated QML components and wrappers in the code-completion popup.
The module versioning point was quite invasive to implement and is still being reviewed. The first point is already in the
kde:kdev-qmljs repository, ready to be tested.
One last thing that I would like to have fixed before the midterm evaluation (next Monday) is the support for built-in QML types (by “built-in”, I mean “part of the core language”). For instance, QML recognizes the vector3d, font, color, date, time, point and rect types, that must be recognized, highlighted as types, and some of them even have attributes (rect has x, y, width and height). This should not be too difficult: I just have to add some components to the plugin.qmltypes files of QtQuick 2.0 and QtQuick 1.0 (both need to be modified because Font has a different definition in QtQuick 1.0 and QtQuick 2.0).