Progress in the local side:

"Draw" entry added to the Back menu connected to a confirmation dialog.
Points to a miniature.draw() function that needs to be implemented.

Pending: a dialog to be shown if the opponent refuses the draw request.


Progress in the remote side:

The frontend shows a gameoverDialog connected to Miniature.ResultDraw but
the backend part needs to be implemented.

Pending: a dialog to be shown when the opponent requests a draw.

(In reply to comment #1)

> Pending: a dialog to be shown when the opponent requests a draw.

UI implemented although I can't test this until the backend pieces are
implemented. See
http://gitorious.org/miniature/miniature/commit/f908b9fb55edffc8c0834a824447a5d0ca6d8ef3
for more details.

Either side (local, remote) can propose and accept a proposed draw, right?

So let's go through the cases:
1. Remote side proposes draw,

2. Dialog pops up, asking local side to accept or reject to draw proposal.
Impl: This requires some imperative action from the Miniature frontend.
Considering that you already have a dialog, how about exposing a boolean
property, say, Miniature::hasPendingDrawRequest. This could be bound to the
dialog's visibility?

3.a Local side accepts draw
Game ends, QML notifies backend through Miniature.acceptDraw

3.b Local side rejects draw
Game continues, no notification?

3.c Local side makes a move?
Game continues, no notification? This interaction model becomes possible if
instead of a dialog, we'd only show a system message in chat area when draw was
proposed from remote side. Local side then goes to back menu to accept draw. OR
taps on chat area and we place a button near system message: "Accept draw".

1. Local side propses draw.
Game continues, QML notifies backend through Miniature.proposeDraw

2.a Remote side accepts draw
Game ends, dialog pops up notifing local side.

2.b Remote side rejects draw
Game continues, local side gets information through system message in chat
area?

2.c Remote side makes a move
Game continues, no notification?

(In reply to comment #3)
> Either side (local, remote) can propose and accept a proposed draw, right?

Yes

> So let's go through the cases:
> 1. Remote side proposes draw,
> 
> 2. Dialog pops up, asking local side to accept or reject to draw proposal.
> Impl: This requires some imperative action from the Miniature frontend.
> Considering that you already have a dialog, how about exposing a boolean
> property, say, Miniature::hasPendingDrawRequest. This could be bound to the
> dialog's visibility?

UI implemented. Search Miniature.ProposedDraw 

> 3.a Local side accepts draw
> Game ends, QML notifies backend through Miniature.acceptDraw

UI implemented. Search miniature.acceptDraw() (sending the command) &
Miniature.ResultDraw (triggering the gameOver dialog)


> 3.b Local side rejects draw
> Game continues, no notification?

No. When the local user moves a piece the FICS server interprets this as a
declination and communicates to the remote player "MiniatureTest has declined"
(or something along these lines).


> 3.c Local side makes a move?
> Game continues, no notification? This interaction model becomes possible if
> instead of a dialog, we'd only show a system message in chat area when draw was
> proposed from remote side. Local side then goes to back menu to accept draw. OR
> taps on chat area and we place a button near system message: "Accept draw".

Nah, too complicated I think. Let's try with the dialog.


> 1. Local side propses draw.
> Game continues, QML notifies backend through Miniature.proposeDraw

UI implemented. Search miniature.draw()

> 2.a Remote side accepts draw
> Game ends, dialog pops up notifing local side.

UI implemented. Search Miniature.ResultDraw

> 2.b Remote side rejects draw
> Game continues, local side gets information through system message in chat
> area?

Yes. Search opponentDeclines, which is the temporary solution I have
implemented in order to have the string "FICS: %1 has declined your request."
available. Note that it is a catch-all sentence that can be reused for adjourn
& abort requests. In practice there should be something like a set() to insert
that string to the model, right?

> 
> 2.c Remote side makes a move
> Game continues, no notification?

If that happens the FICS server will send a message. We could parse it and use
again opponentDeclines whenever it is received.

Let me do a test to post here the exact FICS message, but first I will post
this long comment just in case.  :)

When remote side types "draw": 

- remote side sees "Draw request sent."
- local side sees (in SDK) "GuestBVNP offers you a draw."

When local side moves a piece:

- remote side sees "GuestWSCS declines the draw request."
- local side sees (in SDK): "fics% You decline the draw request from
GuestBVNP."

Fixed in master with commit 1364f0f64dabb5f50fb0801c9c6f9f3bd43f6fab. Adjourn
and abort can be handled in a very similar way, although we yet don't know how
to resume games (for adjourn). Anyway, for 0.5, this is more than fixed ;-)

Reopening:

The reasoning of a Draw still appears as "XYZ vanished", probably because
Miniature.ReasonDrawAccepted is not being used.

Also, note that in the new connections for requests rejected by the remote side
we can use the string already localized found in line 158: 

property string opponentDeclines: qsTr("FICS: %1 has declined your
request.").arg(remoteSide.id)

I can implement the latter tomorrow if you agree.

Pushed a fix to master – please try again!

This works now.

qsTr("FICS: %1 has declined your request.").arg(remoteSide.id) is still not in
use. I will try and commit this later today since we have the string and
already translated to all languages.

(In reply to comment #9)
> This works now.
> 
> qsTr("FICS: %1 has declined your request.").arg(remoteSide.id) is still not in
> use. I will try and commit this later today since we have the string and
> already translated to all languages.

We cannot use that translation string. The API for appending messages requires
two parts, the sender of the message and the message. But if I split up the
above string and tried to use the "%1 has declined your request." parts, then
I'd be introducing a new translation string :-(