Winboard Forum

How can I change the colors of the squares in xboard? The default colors are not good in a monitor I have. I would need to have something better to distinguish whether there is a black piece in a black (dark green) square. In version 4.2.7 I was using pixmaps but apparently they are now disabled. I looked for a solution but I cannot find any.

Miguel
[EDIT]
I hacked xboard to solve it.
In "common.h" I replace these lines:

Code: Select all

/* old lines commented out
#define WHITE_PIECE_COLOR   "#FFFFCC"
#define BLACK_PIECE_COLOR   "#202020"
#define LIGHT_SQUARE_COLOR   "#C8C365"
#define DARK_SQUARE_COLOR   "#77A26D"
*/

/* new colors */
#define WHITE_PIECE_COLOR   "#FFFFF0"
#define BLACK_PIECE_COLOR   "#202020"
#define LIGHT_SQUARE_COLOR   "#EEE9C4"
#define DARK_SQUARE_COLOR   "#DBD295"


Now I like the colors way much better in my monitor (BTW, I always found the default colors dreadful)
Maybe it is just me, but I wonder whether the default colors should be changed...

Pixmaps should still work, I did not change anything there. Futhermore, there are options -lightSquareColor and -darkSquareColor. What you did is change the default setting for those options. But you could have used the options themselves to ask for a setting different from the default.

H.G.Muller wrote:Pixmaps should still work, I did not change anything there. Futhermore, there are options -lightSquareColor and -darkSquareColor. What you did is change the default setting for those options. But you could have used the options themselves to ask for a setting different from the default.

I tried all that but It did not work. I will get back to it because, obviously, I did something wrong. I gave up too easily because I thought it was supported in winboard and not xboard since it is what I found in winboard.ini. Also, I recalled that you planned to remove pixmax support and I thought you did. I just updated my OS and I must have messed up some files.

Anyway, for now my violent hack is ok

Miguel

i remembered i just changed the square colors before in xboard by using command line arguents when i started the program. similar to adding -sgf mygames.pgn you can add arguments for most everything else. I googled and found this:

-whitePieceColor color
-blackPieceColor color
-lightSquareColor color
-darkSquareColor color
-highlightSquareColor color
Colors to use for the pieces, squares, and square highlights. Defaults:
-whitePieceColor #FFFFCC
-blackPieceColor #202020
-lightSquareColor #C8C365
-darkSquareColor #77A26D
-highlightSquareColor #FFFF00
-premoveHighlightColor #FF0000




I believe this information is accessible in the help index but here is the link in tim manns site: http://tim-mann.org/xboard/xboard_3.html

Mike

PulsarMike wrote:i remembered i just changed the square colors before in xboard by using command line arguents when i started the program. similar to adding -sgf mygames.pgn you can add arguments for most everything else. I googled and found this:

-whitePieceColor color
-blackPieceColor color
-lightSquareColor color
-darkSquareColor color
-highlightSquareColor color
Colors to use for the pieces, squares, and square highlights. Defaults:
-whitePieceColor #FFFFCC
-blackPieceColor #202020
-lightSquareColor #C8C365
-darkSquareColor #77A26D
-highlightSquareColor #FFFF00
-premoveHighlightColor #FF0000

I believe this information is accessible in the help index but here is the link in tim manns site: http://tim-mann.org/xboard/xboard_3.html

Mike

Yes, but it did not work for me. I just tested it again

This command:
./xboard -fd ~/cc/engines/gaviota-0.56/ -fcp ./gaviota -darkSquareColor #77A26D

Gives me
xboard: unrecognized argument -darkSquareColor

It does not recognize -darkSquareColor #77A26D but it worked with, for instance, -darkSquareColor blue
That is why I could not get it to work. If this ever worked with #RGB numbers (did it?), now it seens to be broken.

Miguel
[EDIT]
I just downloaded xboard 4.2.7-7 and it does not work with #77A26D but it works with "blue" etc.
So, this feature never existed or was broken long time ago.

H.G.Muller wrote:Pixmaps should still work, I did not change anything there. Futhermore, there are options -lightSquareColor and -darkSquareColor. What you did is change the default setting for those options. But you could have used the options themselves to ask for a setting different from the default.

I just checked again pixmaps and I could not get them to work.
As an example, this command inside the folder that contains xboard 4.3.15
./xboard -fd ~/cc/engines/gaviota-0.56/ -fcp ./gaviota -pixmap ~/cc/xboard/alpha/marthasvineyard

gives me:
Loading XPMs...
1 2 3 4 5 6 Error -1 loading XPM file "/home/miguel/cc/xboard/alpha/marthasvineyard/.ll88.xpm"

I just tested the exact same command with xboard 4.2.7-7 and it worked. I do not know what it could be.

Miguel

You are right, I have broken this feature. The reason is the extra piece types, which translate to a period for single-character name in games where they are not participating. So XBoard tries to load .ll88.xpm here, the pixmap for a white '.' on a light square. And of course that pixmap does not exist in the set you provided.

The work-around for now is to provide the 4 files .ll88.xpm .ld88.xpm .dl88.xpm and .dd88.xpm. Just make them copies of the corresponding King pixmaps kll88.xpm etc. This mean that every piece that does not occur in the variant that was selected at the time you load the pixmaps (i.e. at startup) will show up as a King.

To fix it fundamentally I must not use the PieceToChar function to translate the internal piece type to a character for use in the pixmap file name, (because that is variant-dependent, and does not contain all pieces), but use a fixed mapping containing all pieces. And then not make it a fatal error when a piece that does not occur in the current variant has no pixmap for it. I will do that in the next version. Thanks for spotting the bug.

The color stuff remains a mystery. XBoard uses a call from the X-toolkit XtConvert, to convert the XtRString to XtRPixel. I guess what really would have been needed is to convert from XtRColor to XtRPixel or XtRInt to XtRPixel. I will try to figure it out.

Yes, but it did not work for me. I just tested it again

This command:
./xboard -fd ~/cc/engines/gaviota-0.56/ -fcp ./gaviota -darkSquareColor #77A26D

Gives me
xboard: unrecognized argument -darkSquareColor

It does not recognize -darkSquareColor #77A26D but it worked with, for instance, -darkSquareColor blue
That is why I could not get it to work. If this ever worked with #RGB numbers (did it?), now it seens to be broken.

Miguel
[EDIT]
I just downloaded xboard 4.2.7-7 and it does not work with #77A26D but it works with "blue" etc.
So, this feature never existed or was broken long time ago.

You can use the hex RGB colours with darkSquareColor/lightSquareColor by preceding them with a backslash.

e.g.
xboard -ncp -darkSquareColor \#FAEBD7 -lightSquareColor \#B2BEB5

I found that for the darkSquareColor/lightSquareColor options to take effect I had to first set the background texture files to an empty string.

xboard -ncp -liteBackTextureFile \"\" -darkBackTextureFile \"\"

To restore them back to the default wood effect you can use:

xboard -ncp -liteBackTextureFile \"/usr/local/share/games/xboard/wood_d.xpm\" -darkBackTextureFile \"/usr/local/share/games/xboard/wood_d.xpm\"

This is on xboard 4.5.1

JC

Yes, you are right. It seems '#' is a special character to the shell, so it has to be escaped to be passed to XBoard at all. The double quote of course is special to the shell, and protects other stuff that is between those from being interpreted as special. But an unexpected feature of the shell is that when there is nothing between the quotes, it does not consider it a null-string argument, but is removes the argument altogether from the argument list. So passing an empty string on the command line does not work.

For the texture files there is the alternative to give "*" as an argument, as names starting with an asterisk are ignored. This was a feature in Winboard_x, to quickly disable the texture, without losing the filename, when editing the settings file. You could then simple prefix an asterisk, and delete it later. It would have been neater if there had been a separate Boolean option to enable the textures, like -texture true|false; then you could disable them from the command line without losing the filenames. Perhaps I will add such an option.

None of these problems with quotes and # occur when XBoard reads them directy from a settings file, as there is no intervention of the shell in that case. So editing the ~/.xboardrc file, that already has all these options in them (so you would only have to alter the values) remains possible, and is less tricky (but more cumbersome).

Note that the new XBoard alpha version from the "popups" branch of the hgm.nubati.net repository has menu dialogs with items for all these options (pixmap directories, square colors, board textures in the "View -> Board..." dialog, for instance). See http://hgm.nubati.net/news.html for a description.