Change of policy on game_changed_state(). Originally, it was called

by the midend every time the game state changed _other_ than as a
result of make_move(), on the basis that when the game state changed
due to make_move() the game backend had probably noticed anyway.
However, when make_move() split up, this became more fiddly: if the
game_ui had to be updated based on some property of the final game
state, then execute_move() couldn't do it because it didn't have a
pointer to the game_ui, but it was fiddly to do it in
interpret_move() because that didn't directly have a copy of the
finished game state to examine. Same Game (the only game to be
affected) had to deal with this by actually having interpret_move()
_call_ execute_move() to construct a temporary new game state,
update the UI, and then throw it away.

So now, game_changed_state() is called _every_ time the current game
state changes, which means that if anything needs doing to the
game_ui as a result of examining the new game state, it can be done
there and save a lot of effort.

[originally from svn r6087]

1 files changed, 4 insertions, 0 deletions

diff --git a/midend.c b/midend.c
index 691c643..b5ce237 100644
--- a/midend.c
+++ b/midend.c
@@ -491,6 +491,10 @@ static int midend_really_process_key(midend_data *me, int x, int y, int button)
             me->states[me->nstates].movetype = MOVE;
             me->statepos = ++me->nstates;
             me->dir = +1;
+	    if (me->ui)
+		me->ourgame->changed_state(me->ui,
+					   me->states[me->statepos-2].state,
+					   me->states[me->statepos-1].state);
         } else {
             goto done;
         }