Bug 12410 - OnlineBoard: Implement item "abort" in back menu
: OnlineBoard: Implement item "abort" in back menu
Status: NEW
Product: Miniature
UI
: master
: All All
: Medium enhancement (vote)
: ---
Assigned To: Quim Gil
: general
:
:
: 12411
:
  Show dependency tree
 
Reported: 2011-09-12 23:21 UTC by Uwe Kaminski
Modified: 2014-03-08 10:29 UTC (History)
2 users (show)

See Also:


Attachments


Note

You need to log in before you can comment on or make changes to this bug.


Description Uwe Kaminski (reporter) 2011-09-12 23:21:28 UTC
SOFTWARE VERSION: 
master

EXACT STEPS LEADING TO PROBLEM: 
1. Run miniature and connect to server
2. Accept a game seek or start a game -> OnlineBoard appears
3. Tap onto the back menu button

EXPECTED OUTCOME: 
Back menu contains an item "abort" to end the game in move 1 or make an abort
game request.

ACTUAL OUTCOME: 
No "abort" item implemented

OTHER COMMENTS:
FICS help file for abort: http://www.freechess.org/Help/HelpFiles/abort.html

This is a main feature IMHO but not necessary to run a complete game on FICS so
it should be a post 0.4 feature.
Comment 1 Uwe Kaminski (reporter) 2011-09-12 23:22:08 UTC
This feature is needed for testcases 1.*.* in:
http://wiki.maemo.org/Miniature/Development/testcases#Game_Endings
Comment 2 Quim Gil 2011-09-18 08:12:43 UTC
Proposing for 0.5 - needs to be confirmed.
Comment 3 Quim Gil 2011-09-24 00:26:18 UTC
Uwe, can you investigate when an abort request can be sent? Only with 0-1 moves
or...?

Ideally the Abort option should be visible in the menu only when the user can
actually request it.

Also for mikhas, we should be able extract the number of moves from the
backend.
Comment 4 Quim Gil 2011-09-24 01:54:44 UTC
Progress in the local side:

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

Question: is there a situation when the opponent can accept/refuse or there is
not such thing as "abort request"?
Comment 5 Uwe Kaminski (reporter) 2011-09-24 21:23:32 UTC
(In reply to comment #3)
> Uwe, can you investigate when an abort request can be sent? Only with 0-1 moves
> or...?

An abort request can be sent during the whole game.

An example for an abort request after more than 1 move:

FICS: "okmko would like to abort the game; type "abort" to accept."

> Ideally the Abort option should be visible in the menu only when the user can
> actually request it.

It should be an available option in the back menu during the whole game.

(In reply to comment #4)
> Question: is there a situation when the opponent can accept/refuse or there is
> not such thing as "abort request"?

Yes, every time the player creates an "abort request" after turn 1 the opponent
has to accept or decline this request.

This is already visible in the test case table I created in the wiki:
http://miniature-chess.org/wiki/Test_cases (case 1.4.1)
Comment 6 Quim Gil 2011-09-26 22:08:31 UTC
Ok, this actually simplify things. Thanks!
Comment 7 Quim Gil 2011-09-27 01:28:40 UTC
Thinking of 

> 1.3.2 	Abort request after turn 1 by player:Opponent declines 

You propose:

> An information banner should appear for 5 seconds: "Request declined by 
> Opponent" 

What about using the chat area to post this information? It's there and we can
make more use of it. Whatever text appears there will be 100% cross-compatible
and reliable compared to Harmattan's banners, which we haven't used yet in
Miniature.
Comment 8 Uwe Kaminski (reporter) 2011-09-27 21:59:12 UTC
(In reply to comment #7)
> Thinking of 
> 
> > 1.3.2 	Abort request after turn 1 by player:Opponent declines 
> 
> You propose:
> 
> > An information banner should appear for 5 seconds: "Request declined by 
> > Opponent" 
> 
> What about using the chat area to post this information? It's there and we can
> make more use of it. Whatever text appears there will be 100% cross-compatible
> and reliable compared to Harmattan's banners, which we haven't used yet in
> Miniature.

I like the ideo of using the space used by the chat area at the moment. It' eye
catching but not too much. An other advantage is that the message is visible
until an other message or chat message appears and not until a time frame is
passed.

1. I propose to use an other color (yellow?) than the standard chat-color for
"system messages"

2. Messages from the FICS-Server could be displayed in a third color (e.g.
light blue). This would be also part of the implementation of Bug 12371

3. If 1. or 2. is implemented we need a possibility to filter by types of
messages. This could be done by a long tap into the chat area (or maybe by
taping into the chat area using two fingers?) An Standard dialog could appear
and let the user enable or disable the different types of messages.

What we should remember is that other devices like the N900 do have less space
which results as a thinner chat area. Essential messages should be displayed in
one or two lines.

My Opinion in a nutshell: Let's use the chat area in a different color for
system messages in 0.5. The other proposed stuff could be enabled later.