Bug 12390 - Make last turn visible
 Summary: Make last turn visible
 Product: Depends on: Status: VERIFIED FIXED Miniature Component: UI Version: master Platform: All All Importance: High enhancement (vote) Target Milestone: 0.5 Assigned To: Quim Gil QA Contact: general URL: Keywords: 12421 12393 Show dependency tree

 See Also: Reported: 2011-09-10 23:10 UTC by Uwe Kaminski Modified: 2011-10-13 23:33 UTC (History) CC List: 3 users (show) jukey michael quimgil

Attachments

 Note You need to log in before you can comment on or make changes to this bug. Uwe Kaminski (reporter) 2011-09-10 23:10:47 UTC SOFTWARE VERSION: master EXACT STEPS LEADING TO PROBLEM: 1. Run Miniature 2. Connect to FICS without using TEST MODE 3. start a game 4. make a move 5. let the opponent make a move EXPECTED OUTCOME: The last turn (own turn or opponent's turn) is shown on the board ACTUAL OUTCOME: No visualization and even no log to look for the last turn OTHER COMMENTS: In "mobialia chess" for Android there is a cool "arrow based" visualization implemented. There is a yellow arrow between origin and destination field. Other clients like eboards are using a special colour to show the latest turn. Anyway, this feature is nice to have now (IMO) hence it's nothing for the 0.4 release. Quim Gil 2011-09-18 08:08:26 UTC Proposing for 0.5 - needs to be confirmed. Quim Gil 2011-09-22 09:27:02 UTC https://www.transifex.net/projects/p/miniature/ !!!! Translation work can start. :) Quim Gil 2011-09-22 09:27:27 UTC Ooops, wrong bug sorry. Quim Gil 2011-09-27 01:45:52 UTC A proposal for a visual effect: 1. Piece moves fast from origin to destination in a transition the user can see. Specific effect to be seen after real tests, In principle QML offers many possibilities. 2. Square of destination is briefly highlighted à la wrongTap, just in blue instead of red. 3. Some non-intrusive blue signal is left at the square so the user can still see the moving piece highlighted if he wasn't paying attention during the <1s the whole transition lasted. A question about the model operating the board: is it technically the same piece moving from square A to B, or what in reality happens is that one piece vanishes and another that looks alike emerges? As far as I know the difference is important because in the first case applying the transition is easy, but in the second I'm not sure. About the arrow, interesting. How does it work exactly? Does it stay in the board, only for a short time? Before /n during / after moving the piece...? Uwe Kaminski (reporter) 2011-09-27 13:02:55 UTC (In reply to comment #4) > A proposal for a visual effect: > 1. Piece moves fast from origin to destination in a transition the user can > see. Specific effect to be seen after real tests, In principle QML offers many > possibilities. Not sure if an animation is a good idea because it costs time. And in blitz games you maybe don't have time. > 2. Square of destination is briefly highlighted à la wrongTap, just in blue > instead of red. How log is it highlighted? As long as the animation is running? What is reason for this highlighting? Should it be the same effect like the virtual keyboard shows if I tap onto a character (e.g. If a tap onto "a" I can see the character for a short time above my finger)? > 3. Some non-intrusive blue signal is left at the square so the user can still > see the moving piece highlighted if he wasn't paying attention during the <1s > the whole transition lasted. Do you mean the origin oder destination square? Both of them should show the blue color after the move is done. > A question about the model operating the board: is it technically the same > piece moving from square A to B, or what in reality happens is that one piece > vanishes and another that looks alike emerges? As far as I know the difference > is important because in the first case applying the transition is easy, but in > the second I'm not sure. > > About the arrow, interesting. How does it work exactly? Does it stay in the > board, only for a short time? Before /n during / after moving the piece...? I made a little video to show you the arrows in action: http://www.youtube.com/watch?v=U1Ew6cCjF8M The arrow stays until the next move happens. For me it was never too obtrusively. What else you can see in the video? Possible target fields are highlighted when a piece is selected. This also was never too obtrusively. In a nutshell: I like highlighting of fields and the visualization of the last turn using an arrow but marking origin and target field on board in a light color is also OK for me. I don't like the Idea of animation (yet). :) Quim Gil 2011-09-30 02:06:45 UTC Thanks for the video. Hum, all those events are a bit excessive for the minimalist Miniature... At the end I believe we just have to emulate the experience of a real chess game. eBoard shows only a framed square showing the last piece that has been moved. This is fair enough since in a real game you see the hand of the opponent and where is he leaving the pieces. The square of origin already seems redundant, although it could be signaled with the short wrongTap animation perhaps. To be tried. Arrow and/or animation only for a very short period, like the wrongTap animation. Enough to see it if you are looking at the board when it happens but not staying in the board forever. I find all these elements on the screen distracting. But we can try different combinations as soon as we have the elements in place. I would say that green frame in the square where the moved piece by the opponent sits is the only element required in 0.5. Michael Hasselmann 2011-10-11 01:59:18 UTC Now that I tried yellowish squares for the last move, I think I prefer arrows, too. But that requires a bit more thinking … an arrow cannot be painted by only knowing about one square, it needs to know both. But the current approach computes squares (and how to display them) one by one, independently of others. Perhaps I need a new property that informs the frontend about the last move vector, but then again the backend doesn't know anything about the board's visual size :-) So probably, for ease of use, two new properties: Miniature::lastMoveOrigin and Miniature::lastMoveTarget. Both return an index for the frontend (index \in [0, 63]), which means the frontend needs to be able to draw an arrow overlay from that. Should be possible, since each board cell is *still* a rectangle and such (in the frontend) So we can determine the center of a cell, then draw a scaled arrow that starts in origin's center and ends in target's center? Quim, want to give it a try? Once you can draw such an arrow for a pair of cell indices, I will add above properties. I will still close this bug with my next commit, so if we want to continue with the arrow idea, we need a new bug "Replace last move highlighting with arrow". You might find this confusing, but I am not sure that implementing the arrow in the frontend is entirely trivial and I don't want 0.5 to block on that ;-) Quim Gil 2011-10-11 02:08:02 UTC (((MID AIR COLLISION! Let me post still what I was about to say))) mikhas, I want to draw the following in the last move origin / destination squares: Rectangle { id: lastmoveOrigin color: transparent border.color: "cornflowerblue" border.margin: "4" visible: false } Rectangle { id: lastmoveDestination color: transparent border.color: "olivedrab" border.margin: "4" visible: false } Should I just add this to OnlineBoard, expecting that the model will set them visible in the right squares? PS: I don't want to sound territorial but if we are discarding squares for arrows I want to see it first myself in order to judge - thank you for your undersanding. Quim Gil 2011-10-11 02:11:01 UTC (after reading your suggestion) If you want to resolve this bug you need to set the color of the last destination cell to olivedrab, 4 pixels margin. Or let me do it. :) > Miniature::lastMoveOrigin and Miniature::lastMoveTarget. Both return an > index for the frontend (index \in [0, 63]) Works for me. Will let me implement the squares first and experiment with the arrows later. Michael Hasselmann 2011-10-11 03:22:05 UTC :-) Fixed with commit 92061b9620a406a21dbae47ca8038da888a5124c. You *only* need to change the frontend if you intend to support arrows, as explained above. Quim Gil 2011-10-11 04:13:42 UTC Mmm... ok, now what happens is that the full blue and full green squares stay full blue and green until the next player moves. This serves the purpose of the bug but imho is not very elegant. This is why I was proposing transparent rectangles with just a 4 pixel border of blue or green. I wonder if I can do this myself from the frontend. You don't seem to have implemented this > Miniature::lastMoveOrigin and Miniature::lastMoveTarget. Both return an > index for the frontend (index \in [0, 63]) And even if you did, I wonder whether there is a way for me to activate those squares only. As we saw, it was easier to define all this in the model. Not reopening until hearing mikhas' reasoning. The solution implemented is none of the ones discussed above... Quim Gil 2011-10-11 04:27:13 UTC Reopening: If you play a second game the whole thing is broken marking the wrong squares. In any case, changing the color of the squares for selecting a move if fine, but keeping them all the time is distracting / disturbing. Try yourselves in real games if you don't believe me. :) Quim Gil 2011-10-11 04:51:31 UTC I think I know what happens. It only works correctly when the local side plays white. Otherwise the move highlights are “mirrored”. Michael Hasselmann 2011-10-11 11:58:50 UTC (In reply to comment #13) > I think I know what happens. It only works correctly when the local side plays > white. Otherwise the move highlights are “mirrored”. Yeah, fixed that part now. Michael Hasselmann 2011-10-13 03:15:12 UTC Also fixed the SquareColor property to now be a SquareStyle property (see bug 12377). Quim Gil 2011-10-13 09:07:21 UTC Finishing the work started by mikhas. Now the last move squares are highlighted only with a colored margen. Enough to be seen without distracting. http://gitorious.org/miniature/miniature/commit/1644b34e05567ecb97aae1bdca0fbbd5c2a3969a Please play extensively with the current UI and verify if you think this is good enough for 0.5. We can discuss more if needed for next releases although minimalistic me thinks this is enough. Maybe adding a short bip or a short vibration (like the one tapping the virtual keyboard) would be a reasonable addition to consider. Michael Hasselmann 2011-10-13 10:57:05 UTC melikes