In my opinion this should work in 0.4. Please set target if you agree,
Quim/Michael.

Do we need another signal in addition to onSeekCancelled and onGameStarted?

When the game is cancelled because the opponent has vanished a dialog should
appear, and pressing OK should send the user to SeekGame and be presented a
cleared list of items starting from scratch.

We are still fixing SeekGame for cancelled seeks, hence making this a
dependency of Bug 12363

FICS handles disconnects as game aborts, and as such, game aborts are on our
list for 0.4 already.

Expected outcome is incorrect: It is not *us* that disconnect from FICS, but
the opponent. Disconnect dialog is meant for the former.

What should happen instead is that the game aborted dialog pops up, perhaps
giving a specific reason such as "Opponent disconnected."

Commit 680a01beb8ce46d0b04f7edddeecb3cb70fb1ed9 implements the new
Miniature::gameEnded signal. Currently only works for forfeit-by-disconnect.

UI needs to show a dialog for this.

Question is now for me: How should the backend behave if opponent disconnects?
Just dispose of the game?

Dialog for gameEnded --> opponent disconnects.

It works (tested with desktop + Miniature) but I still haven't found the
way to print the variables for "reason" and "result". Once I know this
then I can edit the UI to have a more explanatory dialog and also can
make the Connections ready for different types of gameEnded.

http://gitorious.org/miniature/miniature/commit/b2b56e83ce8f17b46f2da7c8752023bfa15ab5be


I wonder if always the scenario for a remote disconnection is an adjudication
for the local side? When the local side is a guest then yes, the game is
unrated and it's simply adjudicated to the "survivor". But with registered
players on a rated game I think there are two scenarios:

- Disconnection means courtesyAdjourn.
- Disconnection means victory for the survivor.

Not sure when happens what. In any case the dialog should explain what is going
on... maybe after 0.4.  ;)

After the user presses OK, OnlineBoard is closed and the user goes back to
SeekGame (this already happens), where new seeks show up (this doesn't happen
evn if they show up in console, but this is food for Bug 12340)

(In reply to comment #6)
> I wonder if always the scenario for a remote disconnection is an adjudication
> for the local side? When the local side is a guest then yes, the game is
> unrated and it's simply adjudicated to the "survivor". But with registered
> players on a rated game I think there are two scenarios:
> 
> - Disconnection means courtesyAdjourn.
> - Disconnection means victory for the survivor.
> 
> Not sure when happens what. In any case the dialog should explain what is going
> on... maybe after 0.4.  ;)

Pleas don't forget the case that the opponent was able to re-login and asks for
"resume". How to handle this? There should be a "notification" area or at least
a terminal output window to handle this. But also in post 0.4

(In reply to comment #7)
> Pleas don't forget the case that the opponent was able to re-login and asks for
> "resume". How to handle this? There should be a "notification" area or at least
> a terminal output window to handle this. But also in post 0.4

Resuming games is a separate feature altogether. I just created bug 12376 -
Miniature should be able to resume adjourned FICS games

Now the GameEnded signal is handled properly. Thanks mikhas for your
instructions at #miniature!

Committed to master:
https://gitorious.org/miniature/miniature/commit/402f0dc1b6ed60b9c9b11a8852945d9f7cf516ca

I think the only thing missing to solve this bug completely is to add an option
for Adjourned in the backend (I would just do it as a result next to WhiteWins
etc even if it's not a GameEnded in strictu sensu).

This way we can handle the opponent disconnections no matter how FICS decides
to resolve the case.

I have added two more FICS messages parsed at engine.cc:
https://gitorious.org/miniature/miniature/commit/258d68529a6e3ae3389ec6c5015aae79682de689 

... and that's all I knew or dared to do in the backend. Sorry mikhas but I
still have it too much respect.

One is a game abort and the other is a game adjourned. Both end with a single
character "*". 

I believe with this we have all the disconnection cases covered:
http://www.freechess.org/Help/HelpFiles/disconnection.html

Thanks for doing the basic regex work, I'll add a test for it and hook it up to
the GameEnded command. Taking this bug back for now.

After
https://gitorious.org/miniature/miniature/commit/3f330eae881e1e88da2843b924bd8c2411a285eb
the user experience of a disconnected game has improved a bit: when the local
user clicks OK in the remote disconnection dialog he goes back to SeekGame,
which contains 0 items listed (instead of old ones, as happened before).

What still needs to be done is to set m_filter &= WaitForSeeks in order to make
new resulsts show up. Sorry, I couldn't find the way to do this myself.

We now handle removed seeks that became invalid through disconnect/declines and
games that ended through disconnects and were aborted, lost or adjourned.

Would consider this bug as fixed, at least in the scope of 0.4

Auto-resume after disconnect is a post 0.4 feature, sorry.

I think you went a bit fast resolving this bug as FIXED...  :)

After
https://gitorious.org/miniature/miniature/commit/3428344a47168f736179f08d2f9caf192751a2d2
it is indeed fixed and ready for verification.

WaitForSeeks still needs to be activated but this is the same for any game
resolution implying a step back to SeekGames and we still must implement them.

(In reply to comment #14)
> I think you went a bit fast resolving this bug as FIXED...  :)
> 
> After
> https://gitorious.org/miniature/miniature/commit/3428344a47168f736179f08d2f9caf192751a2d2
> it is indeed fixed and ready for verification.

It was late - thanks.

Tested dozens of times with many scenarios guest / registered, rated / unrated.
Verifying.

We still need a way to report when the player's client disconnected.