One of the uses of a ClutterState state machine along with ClutterScript
is to provide a quick way to transition from state to state in response
to signal emitted on specific instances.
Connecting a real function, in code, to a specific signal does not
improve the ease of use of ClutterScript to define scenes.
By adding a new signal definition to the current one we can have both a
simple way to define application logic in code and in the UI definition
file.
The new syntax is trivial:
{
"name" : <signal name>,
"state" : <state machine script id>,
"target-state" : <target state>
}
The ClutterState instance is identified by its script id, and the target
state is resolved at run-time, so it can be defined both in
ClutterScript or in code. Ideally, we should find a way to associate a
default ClutterState instance to the ClutterScript one that parses the
definition; this way we would be able to remove the "state" member, or
even "style" the behaviour of an object by replacing the ClutterState
instance.
The implementation uses a signal emission hook, to avoid knowing the
signal signature; we check the emitter of the signal against the object
that defined the signal, to avoid erroneous state changes.
dd8cf63a62