hgm wrote:OK, I found the bug. The move of the line that was on top was never stored, so it contained random data that made it always look like it was a different move. So when a lower score for the same move came in to overrule it, it would never be sorted above it, because it didn't realize it was the same move, and that the higher score thus was no longer valid.
The latest snapshot in my http://hgm.nubati.net/cgi-bin/gitweb.cgi 'master' branch now contains a version that fixes this. It also has the feature that you can hide or show columns in the Engine Output window by right-clicking their headers, and with the Polyglot in the 'learn' branch of that same repository it would also allow you to show tbhits, seldep and knps there. (Provided you switch that on in the Engine Settings with the option Polyglot ShowTbHits.)
Very nice. I'll have to figure out how to download your version.
While I am at it, the GTK verion of xboard produces a "strange" board in my computer. The last column (either a or h if the player is black or white) is less wide than the others. It's a bit "ugly" as the letter seems to be cut a bit.
Screenshot attached as always:
I can resize the board by dragging the mouse over it but it doesn't fix the "problem".
To get a tar ball for versions from my repository, just click the 'snapshot' link of the latest (uppermost) commit in the list. Beware that for compiling git versions you might have to issue the command "./autogen.sh" before you can do "./configure".
As to the sizing problem: this looks indeed strange. I will check the GTK code to see how the window size finally calculated from the board size. After sizing XBoard calculates what square size it can afford to fit the board in the indicated area, and then sends a sizing command to GTK to shrink the window around it. This must somehow request a not-wide-enough size.
What is the value of the -size argument in this case? (If you never explicitly requested a size, you can find it in your ~/.xboardrc settings file.) It could be that this has something to do with the initial size.
Thanks for this new version and including the multimonitor fix.
I've created another small patch for a different problem. Namely, when starting analyze mode first thing after starting Winboard and selecting an engine, the engine output windows does not show the multipv and move exclusion line. The small patch at http://octochess.org/misc/backend.diff fixes this.
Thanks for this fix. I now fixed another problem as well: seems that the -stickyWindows option was no longer working in Win8. I now figured out the reason: unlike earlier Windows versions, Win8 always gives sizing parameters with a WINDOWPOSCHANGED event, even if the size stayed the same. This confused WinBoard, so that it did not get to repositioning the other windows that touched.
For the development version I also made an improvement of the 'snap' code, which made a moved or sized auxiliary window snap to other windows: I now also do a sort of reverse snap, where if an edge that was moved in a sizing event was already touching the edge of another window before the sizing started, it drags the latter edge along. This way you can displace the boundary between two touching windows without creating a gap or overlap, which you would then have to undo later in a second sizing effort.
Enlarging the main window by dragging an edge now also works. Before you could only do that by dragging a corner, because it went to the largest board that would fit inside the area. Now it fits the width if you dragged a vertical edge, adapting the height as needed, or fits the hight when you dragged a horizontal edge, adapting the width as needed. Dragging a corner still works as before.
hgm wrote:To get a tar ball for versions from my repository, just click the 'snapshot' link of the latest (uppermost) commit in the list. Beware that for compiling git versions you might have to issue the command "./autogen.sh" before you can do "./configure".
As to the sizing problem: this looks indeed strange. I will check the GTK code to see how the window size finally calculated from the board size. After sizing XBoard calculates what square size it can afford to fit the board in the indicated area, and then sends a sizing command to GTK to shrink the window around it. This must somehow request a not-wide-enough size.
What is the value of the -size argument in this case? (If you never explicitly requested a size, you can find it in your ~/.xboardrc settings file.) It could be that this has something to do with the initial size.
Thanks once more. I'll give a shot at your dev version soon.
As for the size, I assume it is "-boardSize Medium".
