maemo.org Bugzilla – Bug 12410
OnlineBoard: Implement item "abort" in back menu
Last modified: 2014-03-08 10:29:07 UTC
You need to log in before you can comment on or make changes to this bug.
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.
This feature is needed for testcases 1.*.* in: http://wiki.maemo.org/Miniature/Development/testcases#Game_Endings
Proposing for 0.5 - needs to be confirmed.
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.
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"?
(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)
Ok, this actually simplify things. Thanks!
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.
(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.