[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