[Development] Toolability of mixing QML and JS

[Ziller Eike]

On 26.06.2013, at 10:46, Joerg Bornemann <joerg.bornemann at digia.com> wrote:

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

If the property with a "complex" rhs changes the graphical appearance of the item (or of another one), that will not be represented in the graphical designer.
I suppose that is what Kai means with "The best a visual tool can do is warn about their use and ignore them (and hope that the declarative parts can stand on their own)", i.e. "ignore them for the graphical representation of the item(s)".

> 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?

The "declarative part" would need to be able to stand for itself and still resolve to a valid (initial) visual representation of the items. You wouldn't be allowed to do "width: myfancyjscode()". Basically all rhs of the declarative part would need to be "easily resolvable".

The visual designer already just ignores things it deems to be too complex to handle. But that line that the visual designer draws between "easy" and "too complex" expressions is arbitrary and undocumented. (And similar, the line that the current QML implementation draws between "easy == v4" and "complex == v8" is another one that is most probably different to the one in designer.) 

Someone writing a component in code has no idea if the result is manageable by designer. This also breaks one original postulate of QML to be a language with which designers and programmers can more easily work together (the programmer easily breaks the designer's tooling).
Having that fixed in the language instead of having a non-existing or incomplete, changing list of "things that do not work in the visual designer" would help IMO.

-- 
Eike Ziller, Senior Software Engineer - Digia, Qt
 
Digia Germany GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Anja Wasenius
Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B