[Development] Qt Contributor Summit 2019 sessions

[Richard Weickelt]

> I'm wondering if anyone is interested in my experiences with using the
> Qt/Quick technology in a non standard way. I was specifically thinking of
> the QSkinny theming system and the implications of doing scene graph node
> composition ?

What is the latter?

I'm not sure if that is what You have in mind, but I think that QML's
language features:
- declarative by default, imperative only when needed
- uses a simple and widely used language (JS) for imperative tasks
- component-oriented
- property bindings
- dynamic evaluation in flexible contexts

make it a very good foundation for DSLs for automation tasks as well as
description of systems. Qbs is an excellent example how such a QML-ish DSL
could look like (although it's not based upon QML/QtQuick at all) and what
it gains:
- easy to read/understand code
- easy to re-use components
- simple core DSL/concept, but high flexibility

Some example applications (I won't rant on other build automation tools and
their DSLs here):

1. CI systems
Almost all follow a purely declarative approach with YAML and score very
poorly in above 3 categories. Jenkins declarative pipelines are another poor
example (not to mention that the documentation is a maze): No inheritance,
no property bindings, hard to remember...

2. Package managers
Conan abuses Python as a DSL. Poor semantic error messages, high languange
overhead and has to fall back to imperative programming even for the
simplest things.

3. Configuration automation
Ansible uses YAML as the core language and little bit of Python when dynamic
behavior is needed. The languages don't play well together, although I
wouldn't say that the overall result is very poor. But QML would score much
better IMO.

4. Test automation
This is how a Qbs-inspired, QML-based and scalable test automation DSL could
look like: https://qst.readthedocs.io/en/latest/usage.html

To use QML as a DSL, I think it would be necessary to expose more internal
APIs of the QML core. APIs and hooks would be needed to traverse the
component tree and evaluate components or parts of components on demand and
modify contexts as needed. Refer to
https://bugreports.qt.io/browse/QTBUG-69075 for instance.

On the other hand, C++ would probably be a poor choice to implement the
applications (DSL back-ends) I have in mind and this suggestion comes 10
years too late. Languages like Go and Rust are are popular for a reason.

I can't blame the Qt company for not doing this, but I think that an
easy-to-use CI service for Qt applications with a Qbs-alike QML-ish DSL
could have given QML as well as Qbs much more traction. Oh well...

Richard