[Development] Toolability of mixing QML and JS

[Alan Alpert]

On Wed, Jun 26, 2013 at 6:17 AM, Thomas Hartmann
<Thomas.Hartmann at digia.com> wrote:
> Hi,
>
>>
>> Isn't that what "when" is for?
>>
>> states: [
>>      State {
>>          name: "someState"
>>          when: mousearea.pressed
>> …
>>
>> but that's a property change whereas you are talking about connecting to a signal I suppose?  But a property change is notified by means of a signal anyway.
>>
>
> Yes we can use it, bit it has slightly different semantics (as you point
> out). It would be nice also be able to react to signals in a purely
> declarative way.

I agree. There should be a purely declarative approach for all the
"pure UI" parts, and a "triggers" property on State or a
StateChangeConnections element would be an improvement.

Making the UI design more declarative is not just a benefit for
tooling. It's also a benefit for implementation (we can usually
optimize it better) and architecture. The architecture is supposed to
be
1) Declarative QML for the UI look and feel
2) JS for the hooks into the main program functionality
3) C++ for the main program functionality, or JS if the functionality
is really simple or you're prototyping.
The thing is that when we're missing something in the Declarative QML
APIs then you can fall back to JS or C++ to implement it. This is
great in that users of QML don't hit unassailable walls all the time,
but it does allow them to break the intended architecture a lot. What
we want is to extend the declarative QML APIs so that they can
naturally follow this pattern. Then we have a clear architecture,
better design tooling and implementation, and still the unrestricted
power of QML.

With the above architecture, it should be fine for the designer to
treat complex bindings as opaque blocks. If you have declarative
elements for the entire UI look and feel, then the opaque blocks are
hooks into program functionality which would not be expected to be
active inside the design tool (it still makes sense to launch the
application to see it filled with data).

Obviously a complete declarative API is a work in progress. But as a
first step we should consider a "trigger" property on State which you
can set to a signal (e.g. mousearea.clicked) so as to handle that case
declaratively. Do we have a qtquick mailing list yet to use for QML
API reviews?

--
Alan Alpert