chiark / gitweb /
Forbid undo of new-game if it would change the params.
authorSimon Tatham <anakin@pobox.com>
Sun, 1 Oct 2017 09:22:35 +0000 (10:22 +0100)
committerSimon Tatham <anakin@pobox.com>
Sun, 1 Oct 2017 09:38:30 +0000 (10:38 +0100)
commitdb313b3948d27244dd7c34c2609c66d6204d8931
treed92c9a069b6309e0ce7b24d29d667c6ddd2c46ae
parent9f6114e27236105d64e23e063a17db84389059ba
Forbid undo of new-game if it would change the params.

The newgame_undo data was being saved on every call to
midend_new_game, including the one just after midend_set_params when a
new puzzle preset was selected. So you could select a new preset from
the menu, and then press 'u', and the midend would _try_ to undo that
operation and restore the previous game with a different set of
parameters.

This would do the wrong thing in the front end, because front ends in
general will not be expecting that a change of game parameters might
result from an arbitrary keyboard event - they won't be expecting to
have to call the function that moves the highlight in the game-type
menu, for example, and they _certainly_ won't be expecting that a
window resize might be necessary in response to a random keystroke.

One possible response would be to fix all the front ends so that they
_are_ prepared for either of those consequences of a keystroke event,
and then it would be possible to undo not only the New Game menu
option and the 'n' key but also undo any selection of a preset from
the game-type menu, or even a full re-customisation of the game
settings. But that would be quite an upheaval even in _my_ front end
collection, and also probably be awkward for downstream front ends, so
until I'm convinced of the value of going to all the effort, the
simpler approach is just to disallow undoing a new game in those
situations.

(This does mean that re-selecting the _already active_ game preset
from the type menu will be treated as an undoable new-game event,
which I think is an acceptable UI oddity.)
midend.c