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

[Alan Alpert]

On Tue, Apr 29, 2014 at 12:43 AM, Hartmann Thomas
<Thomas.Hartmann at digia.com> wrote:
> 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)

Agreed. This is my personal favorite ;) .

> (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.

Agreed.

While I think that mixing declarative and imperative code in one file
has it's advantages in small projects, there should be a clear line
between "pure declarative and toolable" vs "you're on your own". I'd
like to see something like ".pragma declarative" which defines this
line, such that if you add ".pragma declarative" un-toolable JS blocks
or bindings become compile errors.

> (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.

Agreed (honestly, it should already be there, I guess
https://bugreports.qt-project.org/browse/QTBUG-20453 was never
finished...).

Again, we have some rough plans for a ".pragma strict". Which should ban this.

> (4) Writing (more) QML(JS) static analyzers that can check/enforce a proper strict mode for QML.

Agreed, see ".pragma strict" comments. Speaking of which, this idea
has been around for a while:
https://bugreports.qt-project.org/browse/QTBUG-30069

> (5) Write refactoring tools that help to clean up existing code.

Kinda agree. If we have the two .pragma's mentioned then this is
purely a convenience step (because they can find all cases by using
the .pragmas).

It's probably not worth writing a full refactoring tool that can turn
anything into a .pragma declarative/strict file. Just do what's
convenient to tool and users can do the rest (if they wish).

> (6) Fix/cleanup existing demos and examples.

Agreed. This is probably a good step to do in conjunction with (1), so
as to ensure that the added declarative APIs make sense. In most
cases, the added declarative APIs should make more sense even for the
primitive (non-tool) users and we can verify it here.

> (7) Investigate how we can improve the interplay of QML and C++. Especially in C++/backend heavy projects.

Agreed. Known issues:
https://bugreports.qt-project.org/browse/QTBUG-33233
https://bugreports.qt-project.org/browse/QTBUG-23052
https://bugreports.qt-project.org/browse/QTBUG-19212
Can't find task: More powerful QJSEngine API so that C++
value-type-like objects can be exposed as JS objects when you want
more control at the cost of convenience
https://bugreports.qt-project.org/browse/QTBUG-21844 (in conjunction with above)

But there's probably some additional research to be done too.

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

Yeah, that's always the biggest issue... Every time these discussions
come up there's no major theoretical point of contention. It's just
that the work still hasn't been done and we all like arguing.

--
Alan Alpert