Not necessarily the final design. All the other games have New Game in
the app menu. But I hesitate to put it there without Open and Save.
These are all very much window-specific options anyway.
Maybe it's OK to have window-specific options there, if the app is
single instance. I'm not sure anyone really knows.
And maybe we want Chess to allow multiple instances again. So not
necessarily the final design.
The check in AM_INIT_AUTOMAKE is sufficient. This shouldn't have to be
changed in two places.
It was outdated anyway; automake 1.11 really is important, since it has
all the vala macros.
Saying that you want to save the game, then not getting any save prompt,
is confusing and unexpected. The user should never have any choice in
autosaving anyway; by definition that's something that should happen
without his input.
https://bugzilla.gnome.org/show_bug.cgi?id=702157
Currently you hit a problem when you load a game that had originally
been against an engine, but have no engine installed. Fallback to human
control in this case.
Regression introduced in 894a74a885
Previously, we stored the starting time in the PGN in the standardized
TimeControl field. However this is not sufficient for restarting games
in progress, as the time remaining for each player is not stored. So we
must extend PGN to store the time remaining for each player, and look at
that when starting a game. (Custom PGN extensions are kosher; that's
what we're already doing to store opposing AI and difficulty.)
https://bugzilla.gnome.org/show_bug.cgi?id=701579
Otherwise, the timer event remains in the main loop, and causes us to
crash when it expires. This would happen if the game is not stopped
before starting a new one, e.g. when the player uses "New Game" or "Load
Game" before the previous game has played to completion.
https://bugzilla.gnome.org/show_bug.cgi?id=701705
Vala enums have a to_string method, so if a test produces an unexpected
game result, we can print the symbolic constant instead of just saying
something helpful like "game has result 1 not 3"
This makes the in-game undo action always undo the most recent
move. This prevents a Segmentation Fault when the user selects "Show
previous move" and then attempts to undo move.
v2: don't loop on assignment (review from Michael Catanzaro).
https://bugzilla.gnome.org/show_bug.cgi?id=701601
After ending a game against a chess engine, CPU usage would skyrocket
since the IOWatch on the engine's stdout wasn't removed from the main
loop. Remedy this.
https://bugzilla.gnome.org/show_bug.cgi?id=578130#c7
