[Development] Toolability of mixing QML and JS
Thomas.Hartmann at digia.com
Wed Jun 26 12:00:45 CEST 2013
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,
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:
root.state = "someState";
And it currently has to look like this. There is no real pure
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":
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.
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?
More information about the Development