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

[André Pönitz]

On Tue, Apr 29, 2014 at 07:43:09AM +0000, Hartmann Thomas 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.

Looks good, and realistic.

Andre'