Different highlight of current move (bug/feature?)
Chess Database and PGN viewer
Brought to you by:
hognose
Menu
▾
▴
#52 Different highlight of current move (bug/feature?)
When browsing a game by clicking a move on the subwindow just below the chessboard, the current move in the GameView window is highlighted with black characters on a greyish small background (barely visible on my lcd screen, unless I am right perpendicular to it).
Instead, if a move is clicked directly on the GameView window, it becomes highlighted with white characters on a small blue background. This is much more nice and visible.
Either of the two behavior persists when the user continues to browse the game by using the cursor keys.
Logged In: YES
user_id=655405
Originator: NO
Can you please attach a screenshot showing the bug?
two screenshot merged to compare directly
Logged In: YES
user_id=1728395
Originator: YES
A combination of two different snapshot on a single file in attachment.
File Added: 1717867.png
Logged In: YES
user_id=1728395
Originator: YES
I should add that this looks to me like a feature of Qt. In fact, I observe the same highlighting in the GameList windows. I.e., when I select a game in GameList, it has white-character/blue-background as long as I operate in that window; whereas it has black-character/greyish-background when I operate in the GameView window or in the "SmallWindow" (the one just below the chessboard... does it have a name of its own?). But that is not annoying.
Instead, in the case of this bug report I opened, the weirdness comes from the fact that one *feels* that is operating in the GameView window *even if* as a matter of fact he is operating in the SmallWindow. So my question is: does ChessX really *need* to have "links" (again, what's the name of that?) to browse the game in the SmallWindow? How often do you guys really use it?
(So at the end, this is related to the more general issue "efficient way of browsing a game")
Logged In: YES
user_id=655405
Originator: NO
After yesterday's session I think I understand it. It seems Windows show highlighted text in inactive widget as grey, not blue (that of course depends on your color scheme).
Logged In: YES
user_id=1728395
Originator: YES
That's totally correct. And after yesterday's session I understand that many things I reported as bugs were weirdness of the combination Windows+Qt (evident for me but not for you guys with Linux, BTW), to be considered unwanted features rather than bugs.
So now we have two unwanted features left:
1. (not this case) Semi-highlighted text (grey, not blue) in inactive widgets. Example, in Color panel when one operates in ChessSet listbox. This is (a) probably more acceptable, and also (b) workarounds might be found later.
2. (this case) Semi-highlighted text when one operates in a widget *by mean of* another one. Here, one operates in GameList by mean of GameInfo (AKA SmallWindow). Thus (a) more annoying and (b) maybe indicative of inappropriate design (worth to be consider now).
I think the situation is pretty clear and I feel I also clearly stated my concerns, so now you can go on the way you prefer.
Logged In: YES
user_id=1728395
Originator: YES
Actually, I noticed there is a *third* way of "highlighting" moves on Windows, and that results in having the move surrounded with a tiny dotted line. I can obtain it by pressing the Tab-key when any move is highlighted. It remains that way if I continue to browse the game with only left/right key. (I noticed that also in the past, but only now I was able to reproduce it)
Side note: the unexpected behavior I reported as "TruncateMoves operates while no move is highlighted" (bug report 1718219, now closed as not-a-bug) this way gets a bit worse, because actually TruncateMove can operate while *another* move is highlighted. Though yes, I agree that this "another" move has to be both "reached" and "highlighted" in a weird way (I am certainly not going to open or re-open a bug report on this, it is just to stress that the issue discussed in the *current* bug report might affect also other things).
Logged In: YES
user_id=1728395
Originator: YES
Hi Michal,
to continue the saga of the "different highlight of current move", I have also noticed that when a move is higlighted (with blue background) in GameView and one double-clicks on it, what happens is that only part of the move remains highlighted. More specifically, depending on the exact position of the cursor, what remains highlighted is either (a) the move number or (b) the move itself (e.g. Qd4) or (c) the dot(s) separating the two (this is more difficult to reproduce and can be obtained more easily with the 2nd-3rd dot following a black move).
Also, I've extensively checked several different good Windows applications (Thunderbird, etc.) to see how they manage the different highlights. What I would say is that it is perfectly normal that something remains highlighted (in grey) in a widget while one is operating in a different widget (highlighted in blue), but I *never* saw the other way around (I mean, the widget not used highlited in blue while the widget used is highlited in grey). Instead, this happens with ChessX, for instance when one selects a game from the GameList (it remains highlighted in blue) and then starts to browse it with the arrow keys (thus operating basically in the GameView window).
Can you check if it still applies? I cannot repeat it in newer version of ChessX and Qt 4.5.
It is the same as before, and even more complicated.
When one move on ply X is highlighted and I hit the tab key, then the move is de-highlited and a dotted box surrounds the X+1 move (but the move is not performed on the board). Then...
1. If I carry on hitting the tab key, the dotted box goes on to surround move X+2, X+3, X+4 etc (without performing any move on board). If at the end I hit the right arrow, then the dotted box disappears and it goes back to highlight the move X+1 (and performs that move on the board).
2. If I hit the right arrow, it performs move X+1 on the board but nothing happens in GameText except that the dotted box loses the right edge (yes, strange but true). Then, if I hit again the right key it returns to the normal behavior: move X+2 highlighted and performed on board.
All this with Qt 4.5.0 on Windows Vista.
My suggestion would be to leave this bug open and give it low priority.
Anyway, all of this could be solved if only a way would exist to change the focus from one windows to another, so that when one operates on the moves the focus is *only* on GameText.
The behavior now has changed and focus is assigned basically to GameText.