If the user has resigned, the engine doesn't know the game is over,
because we don't tell it. So if the user resigns immediately after
moving, and the engine has not moved yet, we need to ignore it when it
does.
Fixes#49
When we replay the engine's move later, we should make sure we are still
playing the same game AND that the state of the game is still the same.
Otherwise, discard the engine's move. The user has done something to
advance the state of the game beyond what the engine knows about, so
it's totally expected that the engine's move may no longer apply.
The state of the game ought to always be the same as it was before. Add
an assert just to be sure.
Halfway fixes#49
When the game is stalemated, the chess engine will declare a draw. We
then check if it can claim a draw, and if not, declare that the game has
ended due to an engine bug. Since stalemate is not a valid reason to
claim a draw -- it is a forced draw, not a claimable draw -- this means
we incorrectly claim the engine is broken.
Stalemate requires special handling.
I tried 400 first, but then it's no longer possible to smoothly switch
between narrow and desktop mode. 500 is a bit too big to transition into
the clunky inner headerbar, so let's try 450.
The main headerbar doesn't have enough space to show messages when the
screen is narrow. So when running in mobile mode, let's add a secondary
headerbar.
This is not likely to have a very strong effect, but it's the best we
can do short of writing an entirely new chess engine. The HoiChess
engine seems to be notably easier than other engines, so currently that
seems like the best choice to distribute with GNOME Chess.
Fixes#18, at least sort of.
If we've repeated the same move enough times, we display the claim draw
dialog immediately before ending the game due to the forced draw. This
is wrong: the game is already over, but the user is still prompted to
decide whether to claim draw or not! That's no good.
Way back in 4cabc41085, I thought it was
important to allow users to claim a draw at any point in the future
after a threefold repetition. But this is not what the laws of chess
allow: it should be claimed when it happens, not at random points in the
future. At the time, that change probably made sense because we didn't
tell the user when it's possible to claim a draw, which nowadays we do
by opening a message dialog. But nowadays, it has no benefit, and a
large cost: the message dialog appears at the start of every turn,
forevermore, getting in the way and irritating the user. So let's only
show it if the current board state really is eligible for a draw.
Fixes#47
Fixes:
0 _g_log_abort (breakpoint=1) at ../../../../Projects/glib/glib/gmessages.c:559
1 0x00007f4cae0bf45e in g_logv (log_domain=0x7f4cae122b50 "GLib", log_level=G_LOG_LEVEL_CRITICAL,
format=0x7f4cae122fc0 "Source ID %u was not found when attempting to remove it", args=0x7ffdd5eff9b8)
at ../../../../Projects/glib/glib/gmessages.c:1405
2 0x00007f4cae0bf54f in g_log (log_domain=0x7f4cae122b50 "GLib", log_level=G_LOG_LEVEL_CRITICAL,
format=0x7f4cae122fc0 "Source ID %u was not found when attempting to remove it")
at ../../../../Projects/glib/glib/gmessages.c:1447
3 0x00007f4cae0b4524 in g_source_remove (tag=2921) at ../../../../Projects/glib/glib/gmain.c:2499
4 0x000000000041958e in chess_scene_set_game (self=0x25a0150, value=0x27024e0)
at ../../../../Projects/gnome-chess/src/chess-scene.vala:97
5 0x0000000000423db6 in chess_application_start_game (self=0x22b2320)
at ../../../../Projects/gnome-chess/src/gnome-chess.vala:520
6 0x00000000004341f0 in chess_application_start_new_game (self=0x22b2320)
at ../../../../Projects/gnome-chess/src/gnome-chess.vala:2464
7 0x000000000042afac in chess_application_new_game_cb (self=0x22b2320)
at ../../../../Projects/gnome-chess/src/gnome-chess.vala:1519
