[Development] Toolability of mixing QML and JS

[Thomas Hartmann]

Hi,

I have to agree.
ATM in the Qt Quick Designer most bindings are opaque, but we do 
evaluate them for WYSIWYG if possible.

Some bindings we do "create semantics" for.
Something like id.property is quite easy to "understand" for the tool.

Even pure JS bindings can get have quite complicated semantics, so we 
have to draw a line somewhere.

Some examples of bindings:

root.contentHeight > availableHeight ? root.contentHeight - availableHeight

Math.max(Math.min(recentProjects.contentHeight + 120, 
recentProjects.height), sessions.height)

While we have of course the AST and the code model this does not help 
much, if we would try to provide graphical tooling for these kind of 
expressions. We would need a full blown graphical expression editor.
(Expressions would be a graphical tree with operations as nodes and 
values as leafs.)
While this would be possible, I do not think of this as "cost efficient".

But I do not see the problem with treating these kind of bindings as 
opaque blobs and just providing a text edit/jump to code for them, while 
evaluating them for a proper preview.

What hurts us more is real imperative code. For example setting a state 
usually looks like this:

onSomething {
    root.state = "someState";
}

And it currently has to look like this. There is no real pure 
declarative way.

While we can detect and understand simple patterns like the one above, 
we will fail for more complex code. This is the problem with all UI 
editors that (have to) touch imperative code.

My idea is to (slowly) extend QML by Components/patterns that are purely 
declarative and that are used by the tooling.

Something like a "StateChangerConnection":

StateChangerConnection {
    target: root
    signal: "something"
    targetState: "someState"
    sourceState: ""
}


Then we can ignore any imperative code.

Since we do have a working rewriter there is no difference for us, if we 
ignore code from a .js file or code written inline.

We do rewrite anyway and therefore we preserve anything we ignore/do not 
understand on a semantic level.

Kind Regards,
Thomas Hartmann


Am 26/06/2013 10:46, schrieb Joerg Bornemann:
> 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.
>
> 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?
>
>
> Cheers,
>
> Joerg
>