[Development] Toolability of mixing QML and JS

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


Hi

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