Even though the original ChessGame is always destroyed immediately after
the creation of a new one (no other reference to it exists), the signals
we connected to the original game may be nonetheless fired by the NEW
game object. This must be a bug in Vala signals.

https://bugzilla.gnome.org/show_bug.cgi?id=732067

The existing check for linux/prctl.h works great if you are compiling
the Vala code, but it's expected that users and distributions may start
with the distributed C files instead. If the tarball is generated on
Linux, then the call to prctl() will unconditionally appear in the
distributed C, and if the tarball isn't generated on Linux, then it will
be unconditionally absent.

There are only two ways to fix this: (a) not distribute any C code, or
(b) move the conditional compilation out of the Vala code. Though it
looks like the Autotools Vala world may be starting to lean towards (a),
let's be conservative and pick (b) for now.

https://bugzilla.gnome.org/show_bug.cgi?id=726614

If we crash or receive a signal that kills us, the chess engine might
live on forever. Linux (and only Linux) provides a nice way to avoid
this by tying the life of a child process to its parent. Use it.

(To get equivalent behavior on other systems, we would need to fork a
third process to function as a monitor, which is not worth the bother.
Non-Linux users should simply not crash the game.)

You'd think I would have noticed the colors were wrong when I fixed the
pieces. You'd think wrong!

The rule is that everything is the same *with the same player to move*

https://bugzilla.gnome.org/show_bug.cgi?id=705956

https://bugzilla.gnome.org/show_bug.cgi?id=706264

Looks like this got broken at some point

https://bugzilla.gnome.org/show_bug.cgi?id=703860

Since Claim Draw provides no user feedback when a draw cannot be
claimed, we should not let the user select this item at all unless it
will work.  This is for the stable branch only; for master, we want to
actually display an informative dialog to explain what's wrong.

https://bugzilla.gnome.org/show_bug.cgi?id=703841

Michael I Doherty authored Aug 12, 2013 and Michael Catanzaro committed Aug 12, 2013

Presenting preferences dialog in full-screen mode makes the main window
disappear from view, as it is not transient for the main window

https://bugzilla.gnome.org/show_bug.cgi?id=705823

The halfmove clock was reset to zero each time we copied a ChessState
object.

It's not enough to check if the current board state has been repeated
three times.  We don't end games automatically for threefold repetition,
so it's possible to play past it.  Calling the draw at any point
afterward should work.

We were considering the value of the previous move in the check for
threefold repetition.  But the move is not relevant; the only thing that
matters is that the board state is the same.

https://bugzilla.gnome.org/show_bug.cgi?id=704993

https://bugzilla.gnome.org/show_bug.cgi?id=703837

https://bugzilla.gnome.org/show_bug.cgi?id=703837

https://bugzilla.gnome.org/show_bug.cgi?id=703842

The user expects this to function as "cancel"

https://bugzilla.gnome.org/show_bug.cgi?id=703857

This reverts commit a83014ec,
which was a bad idea for a cherry-pick.

E.g. if you resign, the game wants to be saved to reflect that
resignation

https://bugzilla.gnome.org/show_bug.cgi?id=702157

Moreover, we should wait until after the save is successful before
making this determination.

https://bugzilla.gnome.org/show_bug.cgi?id=702157

Conflicts:
	src/gnome-chess.vala

I planned to do this when picking the change into gnome-3-8 from
master, but forgot. We can't use the pretty default filename in
gnome-3-8 due to string freeze.

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 894a74a8
(cherry picked from commit 79087ca62e76063011853f22ea0c1edd442f4499)

(cherry picked from commit 8705a4adf3c08cba03f4681580ec7ddde502cda4)

This means people will save with the .pgn extension by default, yay.
(cherry picked from commit ec1c2587)

White should have unlimited time for his first move.

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

https://bugzilla.gnome.org/show_bug.cgi?id=701636
(cherry picked from commit cb03e2ff)

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
(cherry picked from commit 7862319a)

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
(cherry picked from commit 32d04f0b)