[Development] Perceptions/Understandings of the QML language [was: Question about Qt's future]

[Rutledge Shawn]

On 29 Apr 2014, at 3:34 PM, md at rpzdesign.com wrote:

> Is there a class diagram on the current code base?

You can run doxygen on it and get the automatically-generated ones, but AFAIK there has never been any emphasis on doing "internal" documentation, only user-facing documentation.  I don't know all the reasons why.  For one thing we don't have an agreement on where to put hand-created "internal" docs in the git tree.  Probably nobody wants to put a lot of time into doing it by hand anyway, and it would tend to stay out of date unless it was automatically generated.  From experience I can say that they aren't quite as useful for everyday reference as you would think, unless they are integrated into your workflow interactively instead of just being a static diagram that you hang on the wall (even if you could find a big enough sheet of paper for a Qt class diagram). And diagrams generated by static code analysis don't show all the object relationships that will exist at runtime.  It could be introspected at runtime though.

Doxygen is good at generating class diagrams, but we can't use it for all docs because there has been so much divergence in the feature sets that doxygen cannot generate our user docs.  But generating class diagrams automatically with some kind of tool (probably built on "dot" the way doxygen does it) ought to be doable.  (And then where would we put them…)  One big diagram would be too complex, but Doxygen does a good job of using just the relevant subtree on each doc page and letting you click to navigate docs.

Another idea is maybe Creator could have dynamically generated diagrams which can be used to navigate the code, the way you can do in Eclipse.  But a prerequisite would be better support for diagramming applications in Qt Quick 2.  That's one of my long-term background tasks: it would be a good start to be able to draw connected-node diagrams by hand.  (But that in turn depends on having a proper "path" element.)  Automating it should then be doable too.

> This would help newbies when trying to contribute to the refactoring
> strategy.
> 
> The code supporting the QML, JS, and C++ must be layered and sensibly
> separated so that people can "opt-in" on various parts at compile/link time.

I would like that too; at least the scene graph should be separable from Qt Quick so that other language bindings become possible. The usual answers I've heard to that proposal are

1) the scene graph is documented public API (it's just that there is no way to link it without the JS engine and the rest of QtQuick) http://qt-project.org/doc/qt-5/qtquick-visualcanvas-scenegraph.html

2) https://codereview.qt-project.org/#change,52682 will break that link to make a standalone scene graph (but the patch is out of date and doesn't apply cleanly nowadays).  It has been claimed the patch can't be integrated because it's incompatible with building the whole integrated Qt the way we usually ship it.  But I hope we get to a point where it can be.

3) you would lose so much functionality that it becomes uninteresting, or at least you have to redo a lot of work as part of the other language binding.  Much functionality is implemented in the Qt Quick objects: input event handling (including gestures, since we don't have a centralized gesture recognition), bindings, animation etc.  At the same time, if you intend to get rid of baggage, you cannot do without the qtcore and qtgui modules, even if your application doesn't need big parts of it.  But qtgui gives you cross-platform windows and opengl and events, you just have to decide all over again what to do with the events (and from experience, this is tricky to say the least)

Nevertheless, I still think it ought to be possible to build the scene graph without QtQuick, just for what it's worth.

Trying to refactor and separate modules at other points to depend less on JavaScript will run into these issues: 

1) the JS engine would get loaded into memory anyway, because QtQuick increasingly depends on the JS object model.  

2) we value the efficiencies to be gained by tight coupling.  JS objects are more efficient than QObjects and QVariants, so we expect the coupling to become tighter rather than looser.

3) QML and Quick implementation details are private so they can be free to evolve

But can we separate the object model from the interpreter, and make a nice C++ API for that?  I don't know, but it seems daunting, and doing it too early would limit the evolution too much.  Anyway the hypothetical API would only give you a base on which to build applications (or alternative language bindings) in verbose C++ instead of clean-looking QML, and some useful functionality would be left behind.

(disclaimer: much of the above is personal opinion and speculation about which others will disagree)

> When respected people like Thiago Macieira put forth the idea that
> there is no public API at the C++ level for Scene Graph and other QML
> locked in design pieces, that does not smell right.
> 
> Where are the unit tests and test benches for the Qt code base?
> 
> I have not seen a script that runs the test bench/unit tests for this
> large QT code base.  Anybody have insights on that?

Every module has tests/auto with a bunch of unit tests intended to be run automatically.  You can run "make check" on each module to run them.  Every time a patch is integrated in CI, all tests run on all platforms (to the extent possible).