WinBoard/XBoard 4.8.0 released

[hgm]

I can ask for smaller sizes but the empty space is still there and cannot be resized. Seems to be like the clock size remains big and does not adjust.
Anyway, if I start with -buttons, the problem is solved. That seems to correct the size of the clocks. If I start with -xbuttons is when the clocks are big.

OK, found and fixed it.

It was an entirely unrelated problem. XBoard GTK dialogs are formatted as a table with 3 columns (label, text entry, browse button), where elements that need to be broader span multiple columns (e.g. a text-edit that doesn't need a browse button would span column 2 and 3). A bare text label, like the message widget, should have spanned all 3 columns.

The problem was that it only spanned columns 1 and 2. So GTK though there was still a column behind it, but the entire window has nothing in this column. I noticed before that GTK's auto-sizing gets completely confused when this happens, and in stead of assigning it width 0, gives it some random width. Which caused the extra space we were seeing.

When I let bare labels span all 3 columns the problem disappears. (When the button bar was on the same row, this problem was masked, because then all stuff that is on that row is packed into a hbox, which then was told to span all 3 columns. And when there is at least one element in each column, GTK doesn't mess up.)

[op12no2]

Hi hgm,

I've been using Fairy-max 4.7.3 on Windows for months to test my developing engine. I switched to 4.8.0 yesterday and things didn't look right; Fairy-max 4.8.0 seemed to have had her wings clipped and was loosing too many games.

I did a clean install of 4.7.3 and 4.8.0 (ini files untouched), set them up identically in the UI and did a test between them:-

4.7.3 took 19/25 points (80 moves in 1 min repeating). Book set to play first 5 moves for each side at random. Not many games but enough to raise a red flag perhaps.

I realise Fairy-max is generic and performance is probably not really your main focus, but here is the .pgn file should it be of interest:-

http://op12no2.me/stuff/473v480.txt

Subjectively 4.8.0 doesn't seem to search as deep as 4.7.3; 2-3 ply less at times; although nodes counts seem comparable-kindasortaish; so maybe a change to LMR/Futility...?

[hgm]

OK, I will test the old and new versions against each other. I did change something in the game definition of normal Chess, defining the white and black King as separate piece types. (So that it would become possible to multiply the centralization points for a bare King by a large factor.) This required renumbering of most pieces, which in theory could affect the move it tries first in QS. Although I think I did it such that it would not have any impact before it promotes.

There are some minor modifications in the search code (move generator, really, but in Fairy-max they are integrated), which could have a speed impact. But I would be surprised if that mattered more than a percent or so.

[hgm]

Yes, you are right! Thank you for spotting this.

I introduced a major bug. This version counts pieces of each side in a prelude to the search, to detect bare King and then up its centralization score and switch off null move by making it believe material count has dropped to 4. (A major problem in Makruk was that you need so many pieces to force mate that null move was still on, and zugzwang was essential for finding the mate.)

But it turns out I always switch off null move there (when this mechanism can work because white and black Kings are different piece types), not just when one of the Kings is bare.

I guess this is serious enough to warrant an immediate 4.8V release.

[op12no2]

I'll stop my tourney then 4.8 was down 9-44-20. Look forward to having Fairy-max back to her full wingspan...

[michiguel]

I can ask for smaller sizes but the empty space is still there and cannot be resized. Seems to be like the clock size remains big and does not adjust.
Anyway, if I start with -buttons, the problem is solved. That seems to correct the size of the clocks. If I start with -xbuttons is when the clocks are big.

OK, found and fixed it.

It was an entirely unrelated problem. XBoard GTK dialogs are formatted as a table with 3 columns (label, text entry, browse button), where elements that need to be broader span multiple columns (e.g. a text-edit that doesn't need a browse button would span column 2 and 3). A bare text label, like the message widget, should have spanned all 3 columns.

The problem was that it only spanned columns 1 and 2. So GTK though there was still a column behind it, but the entire window has nothing in this column. I noticed before that GTK's auto-sizing gets completely confused when this happens, and in stead of assigning it width 0, gives it some random width. Which caused the extra space we were seeing.

When I let bare labels span all 3 columns the problem disappears. (When the button bar was on the same row, this problem was masked, because then all stuff that is on that row is packed into a hbox, which then was told to span all 3 columns. And when there is at least one element in each column, GTK doesn't mess up.)

Now looks good! Thanks,

Miguel

[Richard Allbert]

hmm i had the gtk launching script set permissions to that assets folder where the themes .png files are. Just to rule it out.

https://www.dropbox.com/s/mkvvrqw5aiq3j ... d.zip?dl=0

Just out of curiosity you have your system set to some language? Everything looked in English, but you got that locale error.

Just tried it, still no checkboxes. Same errors as in the video.

Thanks for trying!

Computer is a Macbook pro late 2013, English.

My old account I transferred from the previous computer was a german computer, but I'm not sure that is relevant.

[JoshPettus]

I was just curious about the language setting on the OS because if you had set it to German and didn't see any german, that might be a sign of a larger problem.

Anyway, the obvious thing to do is to get rid of the OSX-theme entirely, and just use the default one built into the library. Bit of a shame as I had worked pretty hard on getting the other one right. But now it doesn't even make sense in 10.10, and definitely isn't worth this much trouble.

If you can verify the default one works for you, then I'll tell our administrator to remove it from our sources.

https://www.dropbox.com/s/mkvvrqw5aiq3j ... d.zip?dl=0

[Richard Allbert]

I was just curious about the language setting on the OS because if you had set it to German and didn't see any german, that might be a sign of a larger problem.

Anyway, the obvious thing to do is to get rid of the OSX-theme entirely, and just use the default one built into the library. Bit of a shame as I had worked pretty hard on getting the other one right. But now it doesn't even make sense in 10.10, and definitely isn't worth this much trouble.

If you can verify the default one works for you, then I'll tell our administrator to remove it from our sources.

https://www.dropbox.com/s/mkvvrqw5aiq3j ... d.zip?dl=0

Yes all good with this one

It doesn't look that bad at all - I think having the current function and features is more important, well done.

I wish I could be of more help - I've been making GUI's for the Mac for a while, but using Cocao.

[JoshPettus]

Lol, that's quite alright. I wouldn't say I'm a fan of they way gtk does things, or how difficult it is to package. I have seen quite a few projects with QT that look a lot better off the bat on on OSX. But it's what xboard uses, and it's much better then Athena on X11.