[Development] Toolability of mixing QML and JS

[Alan Alpert]

On Thu, Jun 27, 2013 at 12:13 AM, Thomas Hartmann
<Thomas.Hartmann at digia.com> wrote:
> 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.

Looks interesting.

These sound very similar to the transitions in the State Machine
framework, something that people have wanted for a while but is risky
because these are not the same States/Transitions. But if we add
"Triggers", we're kinda at a super-set of State Machine functionality
(while still using the terms all differently of course ).

So I like the idea, but definitely on States and not Transitions
(these Triggers have nothing to do with how a State change is
animated).  If someone wanted to pick this up and implement something,
I bet it could make Qt 5.2 ;) .


>
>
> 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"
> }

How is this supposed to work? That as soon as you reach state A, you
immediately go to state B, just to apply the X->A->B transitions in
sequence?

Couldn't that be better done with an X->B transition which looks like
Transition {
    SequentialAnimation { id: xToB; animations: [ xToA, aToB] }
}

Although I suppose that only works in certain situations...

--
Alan Alpert