> 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 _______________________________________________ Development mailing list Development@qt-project.org https://lists.qt-project.org/listinfo/development
