WinBoard/XBoard 4.8.0 released

[JoshPettus]

Ok good. so it's a configuration problem, not a library linking problem. (I had double checked that and came up cluless) Still weird. But at least that is workable.

Still, normally you would see a more explicit error. such and such could not find file such and such here...

could permissions be an issue?

[JoshPettus]

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.

[hgm]

Still, normally you would see a more explicit error. such and such could not find file such and such here...

Unfortunately that is not automatic. To get the error you would have to test if the pixbuf after the Cairo library call to read it is NULL, and if it isn't request the error code from Cairo, decode it to a readable message and print that. It has all to be explicitly coded, and I am often to lazy to do that. (And I suppose others too.)

I am not sure whether this pixbuf error stems from XBoard code or from something else. Because the checkboxes do not print, is seems logical to assume it is from the attempt to read the pictures of the checkboxes, so that would be in some library code.

Have you tested if you get that same assert message if you intentionally delete or rename the checkbox PGN files?

[JoshPettus]

I had, and I got as an example for one:

Code: Select all

/Users/Joshua/Desktop/XBoard.app/Contents/Resources/etc/gtk-2.0/../../share/themes/OSX-theme/gtk-2.0/gtkrc:223: Unable to locate image file in pixmap_path: "assets/l-checkbox-checked-18.png"

same when I just remove permissions to the file.

So it's really strange I don't see this. I guess it's finding the files and something else is at fault...

I have no doubt it's a gtk error, not an xboard one.


If push comes to shove we can just nix the whole silly theme, and use the default gtk one.

[Evert]

I have to say that the non-standard variants work really well (as long as Xboard doesn't get confused andpicks the wrong one). I was able to watch a few games of Mongolian Shatar (which has some interesting restrictions on how you can deliver mate) and they worked without any problems. It also accepted engine claims without complaint (1/2-1/2 {Black mates, but no shak}).

The only issue I had was that I needed to turn legality testing off while watching a game from a PGN file.

All in all, well done!

[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.

Will look this evening after work.

All is English on the computer.

[michiguel]

Well, these are still intrinsic limitations of the current version. The width of the clock, font sizes and such are all determined by the initial size (either given by an explicit -size argument, or remembered from its value on the previous run in the settings file). We are not at the stage of WinBoard yet, where resizing of the window would trigger a -size recalculation that would become the new setting and change all -size-associated properties accordingly. Resizing after startup affects the board only.

The clipping of the menu texts is necessary to make the menu bar not dominate the window width at small -size values, and is just another of those properties that will not adapt to later user sizing of the window. To get more text you have to start at a larger -size, and then you cannot shrink below that, because, amongst other things, shrinking below it would leave no room for these longer texts. (Note that even WinBoard switches to 1-letter menu texts below some size; in the GTK version this is just done somewhat more gradually.)

So we can consider the problem fixed, and 4.8.0 working as designed now also on your system.

This is how it looks like



Miguel

[hgm]

Well, that would be how it normally looks after you sized the window height to smaller then it was at startup. If you want the clocks to be narrower, you should ask for a smaller -size. At startup I would expect the board to be as wide as the clocks.

[michiguel]

Well, that would be how it normally looks after you sized the window height to smaller then it was at startup. If you want the clocks to be narrower, you should ask for a smaller -size. At startup I would expect the board to be as wide as the clocks.

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.

Miguel

[hgm]

Ooh, you are right. With -xbuttons the window starts too wide for me too. In my case I can size the width back to the width of the board, however (but not smaller).

This is a bit strange, as XBoard requests the window size to be the same as the board size, which definitely should shrink it to the minimum that all the contained elements would allow. So I don't understand how I could be left after startup with a window that can still be shrunk.

But as I can reproduce it, it gives me something to go on.

[Edit] Really strange: depending on -xbuttons the width of the message field is either sgosed as boardWidth-2 or boardWidth-135. If I always choose it as boardWidth-135 the problem disappears. So it seems GTK imagines there is something next to the message field, even when the button bar is off.