Janet's Shenanigans

The Cool Now

With the infrastructure I built in qml-lsp for parsing and analysing QML files, I thought “hm, since doxyqml is just a glorified qml parser –> c++ header file converter, wouldn't it be trivial to write the same thing in go reusing qml-lsp's infrastructure?” And that's exactly what I did. I wrote a 130-line program that faithfully replicated doxyqml's functionality in Go.

By virtue of being a Go program that calls on a pretty optimised parser in C, it ended up being a little over 10 times faster than doxyqml on my system.

I wasn't done there.

I thought “hmm, couldn't I reuse the semantic analysis I did for qml-lsp to improve the output a bit?”

So, that's pretty much what I did.

Currently, the most notable improvement over doxyqml is in producing a better superclass for the output:

doxyqml, with aliased import (import foo as bar):

class Avatar : public QtQuick.Controls.Control {

doxyqml, without aliased import:

class Avatar : Control {

One isn't valid C++ (I'm surprised Doxygen takes it at all), and the other fails to specifically name where Control comes from, leading to issues with Doxygen trying to locate the superclass.

qml-doxygen reuses the semantic analysis from qml-lsp to generate the following output, whether the import is aliased or not:

class Avatar : public QtQuick::Controls::Control {

It's both valid C++, and tells Doxygen exactly where the name is coming from.

The Roadmap

The next thing I'm planning to do is to resolve the concrete type of an alias property, so that documentation generation for aliases can be improved without developers needing to explicitly tell the computer what type the alias points to.

I may also add the ability to “splat” grouped properties with a special sigil, so that something like readonly property AvatarGroup actions: AvatarGroup { } can be expanded into the properties of the AvatarGroup by qml-doxygen, resulting in better documentation.

Tags: #libre