so quicky, I am doing program which demonstrate methods used for computer graph drawing. I need to create timeline or history of actions like ( placeVertex(x,y), moveVertex(newX,newY) etc. ) and iterate through (forward and backwards, automatically or manual)
I already achieved that by using command design pattern but few of these commands are using transitions. First idea was to use Condition interface's lock, await and signal in setOnFinished
between each commands but it led to gui freezing.
I tryed SequentialTransition but it's no use for my problem - can't change properties dynamically between transitions.
Is there a possibility to somehow inform generation that one transition ended and next can run without GUI freezing and drawing?
Thanks!
edit: I ll try to simplify it all Here is my Command interface and one of these commands:
public interface Command {
public void execute();
}
public class MoveVertex implements Command {
public MoveVertex(Data d, Vertex v, double changedX, double changedY){..};
@Override
public void execute() {
Path path = new Path();
path.getElements().add(new MoveTo(v.getCenterX(), v.getCenterY()));
path.getElements().add(new LineTo(changedX, changedY));
PathTransition pathTransition = new PathTransition();
pathTransition.setDuration(Duration.millis(velocity));
pathTransition.setPath(path);
pathTransition.setNode(v.getVertex());
pathTransition.play(); }
}
These Commands are stored in my history class which is basically
private List<Command> history;
And I do going through the list and executing Commands
public boolean executeNext() {
if (history.size() != position) {
history.get(position).execute();
position++;
return true;
}
return false;
}
And I am trying to achieve state when next Command is started only if previous finished. Tryed to put await/signal in between without success.
The solution below uses Itachi's suggestion of providing an onFinished handler to move to a node to a new (random) location after we get to the next location.
It could probably be made more efficient (and simpler to understand) by re-using a single Transition rather than using recursion within the event handler. It is probably unnecessary to create a new Transition for each movement - but, as long as there aren't hundreds of thousands of movement iterations, it should be acceptable as is.