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

[Hartmann Thomas]

Hi,

On Mon, Apr 28, 2014 at 2:34 PM, André Pönitz <apoenitz at t-online.de> wrote:
> I think at least three modifications are inavoidable: For one, things that
> could be written in a declarative way but which currently are only possible
> using JavaScript, a declarative way should be added. Second, it should be
> stressed in the documentation (including the examples), that using
> inline imperative code is naughty. This can be supported by e.g. the QML
> Designer refusing to operate on such files. People can still do that, but
> would be on their own. And finally, and that's also acting as a proof that
> the first two items actually have been done, the JavaScript dependency
> should be _optional_.

Can we turn this into action points we _all_ agree on?
My personal favorites are (In no strict order):

(1) Identify non declarative parts of Qt Quick and add declarative API (e.g. setting states)
(2) Document that inline Java Script and mixing declarative and imperative code in one file has its pitfalls in big projects and creates issues for tooling. Explain the difference between pure declarative QML and QMLJS and the impact on tooling.
(3) Document that accessing ids from other .qml files without any interface (just relying on the fact that they are in the context) creates hard to maintain QML code.
(4) Writing (more) QML(JS) static analyzers that can check/enforce a proper strict mode for QML.
(5) Write refactoring tools that help to clean up existing code.
(6) Fix/cleanup existing demos and examples.
(7) Investigate how we can improve the interplay of QML and C++. Especially in C++/backend heavy projects.

As a second step the actual work has to be done of course.

Kind Regards,
Thomas Hartmann