[Development] Toolability of mixing QML and JS

Thomas Hartmann Thomas.Hartmann at digia.com
Thu Jun 27 09:13:37 CEST 2013


Am 26/06/2013 20:09, schrieb Alan Alpert:

> The difference is that 'when' is a binding evaluated as a boolean, not
> a property change signal. You can do "when: alpha.ready && beta.ready
> && maybeOtherStuff()". You cannot conceptually do "when:
> alpha.readyChanged && beta.readyChanged" because signal && signal does
> not compute. We could assign an arbitrary meaning to it, but I think
> that's getting more confusing by that point...

I agree. We just have to make sure that "triggers" can also react to 
several signals.

We could consider something like this:

State {
    name: "someState"
    triggers: [
       SignalTrigger {
          leave: false //default
          target: someButton
          signal: clicked

       ConditionTrigger {
          condition: someBackEnd.someValue === 10
//Different from when, because state change is triggered when
//condition becomes true, but we do not leave the state  automatically
//if the condition becomes false again.
       ConditionTrigger {
          leave: true
          leaveToState: ""
          condition: someBackEnd.someValue === 12
//This time we leave the state to the base state

This is just brainstorming. We should also consider moving these 
"Triggers" into Transitions instead.

Another feature that I needed sometimes (independent from tooling) was a 
state that automatically changes into another state (for animations).

Something like:

State {
    name: "someState"
    nextState: "someOtherState"

This is currently only doable by ScriptActions.

Kind Regards,
Thomas Hartmann

More information about the Development mailing list