[Development] Toolability of mixing QML and JS

[Koehne Kai]

> -----Original Message-----
> From: development-bounces+kai.koehne=digia.com at qt-project.org
> [mailto:development-bounces+kai.koehne=digia.com at qt-project.org] On
> Behalf Of Joerg Bornemann
> Sent: Wednesday, June 26, 2013 10:47 AM
> To: development at qt-project.org
> Subject: Re: [Development] Toolability of mixing QML and JS
> 
> On 26/06/2013 10:19, Koehne Kai wrote:
> 
> >   - Designer: Any visual designer will only be able to cope with the
> > declarative parts. JS snippets are opaque blobs. [...]
> 
> JS snippets are not opaque blobs. The QML/JS parser provides everything we
> need to understand the structure of the code. A design tool can offer to edit
> property bindings with sufficiently simple code (e.g. JS
> literals) graphically. The tool can let the user edit more complex stuff in a text
> editor.

Opaque blobs was a bit overstating. But it's clear that manipulating/executing them in a context outside of the application has its limits (as Thomas was also pointing out).
 
> I claim it doesn't help at all to have a QML where the rhs of properties is
> restricted to a "JS subset" or another DOM we might invent. The comlex code
> would be in external .js files and property bindings would be just glue. The
> design tool would be able to edit the properties that do not call JS functions
> and open a text editor for the others. How is this different from what we have
> now?

For the Designer, the main difference would have been to set user expectations. It's obvious that you can't expect Quick Designer to reasonably edit a .qml file when you e.g. set up all the layout in the .js file. It would have also forced us to make sure most interesting parts can be done in a declarative way, with no script code needed.

Anyway, this discussion is leading nowhere. We have QML as it is, and we have a Quick Designer that handles things reasonably well. We might still consider with a more restricted version of QML as an alternative for users that want it, but that doesn't buy us much from the tooling perspective, because we have to support the full set anyway.

I just raised the points because Alan was asking why mixing JS and QML was making tooling harder. 

Regards

Kai