Winboard Forum

Superseded by Xboard OSX 4.8

XBoard.app 4.7.3a
For OSX 10.6-10.9

Note - If updating from 4.7.2 app - Due to changes in how XBoard.app finds its data files, the old generated ~/Library/Prefrences/Xboard.conf is not compatible with the new app and will interfere with the new settings needed for xboard to find its data files. If you don't see board textures or pieces, be sure to remove the old file and let xboard generate a new one.



Unlike standard xboard on linux it saves in ~/Library/Preferences/Xboard.conf which would be the standard place on OSX

Unlike other packages, you don't need X11/XQuartz or anything pre-installed. It is all self-contained with GTK2 running directly through quartz. (OSX's native graphic api)
Just copy to wherever you want on the hard drive. For the ICS scripts to work, be sure to keep them in the same folder.

download link
http://www.mediafire.com/download/0k6bt ... 4.7.3a.dmg (No longer available)

----------------------------------------------------------

WinBoard.app 4.7.3a
For OSX 10.6-10.9



This is a port of Winboard to OSX made possible by Wineskin, which is essentially a wrapper for winboard and its supporting programs inside the winboard.app. Together, it is bundled with wine, supporting libraries, and runs on the current wine mac quartz driver. (Wine, which supposedly stands for "Wine is not an emulator," is an implementation of the windows api for Unix systems.) As such, the size of this app comes out to a whopping 420mb total! But, with it, you can run a lot of chess engines made only for windows on your mac. (Lets face it, most of the proprietary chess software out there.) Right now due to lack of wine support for 64bit in mac, this is limited to 32 bit chess engines. How does performance compares to native engines? No idea, but someone can find out.

To install an engine or get at the winboard files, right click on the app, select "open contents," go to the c drive folder, and you will find the winboard files under the winboard folder. Then you may setup your engine just as you would in windows, either within winboard or by editing the winboard.ini

If it comes to it, you can use the wineskin.app inside the wrapper to change wine settings, change the launching .exe, create launchers for other exe's, ect.

There are a few quirks I have noticed with winboard in wine, nothing show stopping though. For instance, to get at the help file click on "What is help?" it will ask for the winhelp.hlp file and just find the winboard.hlp file in the winboard folder. There are probably others. In short, bear in mind, wine can be quirky.

download link
http://www.mediafire.com/download/8sxne ... _-_OSX.dmg

----------------------------------------------------------------

XBoard Xiangqi Edition 4.7.3a
For OSX 10.6-10.9
See note above!



Here is a version of xboard configured to run Xiangqi. (Chinese Chess) It's bundled with a script to launch HGM's variant server as well as his MaxQi and HaQiKid and an opening book. (go to common engine's and deactivate "Has Own Book")

It saves it conf file in
~/Library/Preferences/XboardXq.conf

download link
http://www.mediafire.com/download/42lsh ... 4.7.3a.dmg

---------------------------------------------------------------

XBoard Shogi Edition 4.7.3a
For OSX 10.6-10.9
See note above!



This is a version of xboard configured to run Shogi. (Japanese Chess) It is bundled with 3 engines: Gnushogi which is relatively weak, HGM's Shokidoki which is quite strong, and the super powerful Bonanza 6.0. The large size is due to Bonanza's fv.bin file.

It also includes launching scripts for a few shogi variants, Sho, Chu, and Mini. Sho or Small shogi is the direct predecessor to the modern game, it lacks the drop rule and includes an elephant piece that can promote to a second King! Chu or Middle Shogi also has no drop rule and is a large variant with 92 pieces! It is in fact a simplification of Dai (Large) Shogi and is still played today though it has lost in popularity to the modern game

A huge thanks to HGM for all his fine work!

It saves it's main config in
~/Library/Preferences/XboardSg.conf

http://www.mediafire.com/download/n7wmh ... 4.7.3a.dmg

Gah! It has come to my attention that the dmg for the standard xboard app was unopenable.... (hate it when that happens) I uploaded another one.

Gone and fixed fairymax issues. Sorry about that, was copying from my previous xboard install and forgot how I had compiled it before with an absolute directory

I re-uploaded all three packages. Changes include:

1) Fixed all the unnecessary errors in the terminal upon launching looking for unneeded libraries.
2)Made it so the apps don't launch the terminal when starting xboard. (launching with the included command scripts will still do, which is just as well as it is needed for ICS)
3)included my very minor source changes as a patch inside the app under the "src" folder so to make sure I'm in compliance

Uploaded again!
Changed all shortcuts using Ctrl to Cmd to reflect OSX standards.
Xiangqi Ed. now says "Red" instead of "White" on the clock.
Reflected all changes to code in included patches with each app under the src directory inside the application.

After thinking about it for a long while, I decided to change where xboard.app put its conf file. I originally thought it would be easier to tell everybody to look in the same place ~/.xboard.rc . But now i think it would probably be better to put it in a place a Mac user would look for it which is under the ~/Library/Preferences folder. Hidden files are a little troublesome to get at in OSX having to change hidden flags in the terminal and restart the finder. Unlike LInux where a simple ctrl-h would display them.

I just found out i have been compiling with zippy off. I don't really use it, but I guess I should have it activated incase someone wants to use it.

On top of that I took the opportunity to finally rearrange everything inside each package and tidy it up. I basically had all the supporting bins and engines in the MacOS folder with the Xboard bin which isn't exactly standard as oppose to in the Resources folder. I should have done this a long time ago, but at the time I just wanted to see if I could get everything to work properly.

The only problem is If someone is updating they would have to clear their ~/Library/Preferences/xboard.conf file as the old one would still be pointing to where the texture files use to be and not where they are now.

Oh well better now then later down the road...

I'm starting to notice that this entire thread is one big monolog for me
----

Anyway I took a look at the Help menu in xboard apps to see what I could do there.
The main thing was all the links and email seemed to use a linux command called "xdg-open" to open up other apps. In OSX the command is just "open" So that was a very simple change in args.h. So I once again updated all 3 apps. Now it launches the appropriate default Browser or Email program when one of these links are clicked on.

Xboard.info does work but It requires the user to:
A) Activate xboard in a terminal (which happens automatically if you are using one of the .command shell script) and
B) Have X11 installed either through macports or download Xquartz in order for the info program to render
Not much I can do about this...

Unfortunately Xboard Man doesn't work. I'll have to look into that to see if there is anything I can do, but at least a user can use one of the other options.

So with HGM's help I manged to get the manpage in the help menu working.

But that left me with a small problem. Do I keep using xterm? Problem with xterm is everyone would have to download Xquartz for it to work. The default terminal.app is more then capable of running info and man programs. Problem is Terminal.app is said to actually be a terminal emulator, not sure what that actually means, but one of the things is that you cant pass it arguments via commandline. As a result, many mac users often go to using convoluted apple-script to launch terminal with arguments, but GCC doesn't like that. (at least I tried)

So instead, I took advantage of the fact OSX automatically opens terminal.app when opening a shell script labelled .command. I created two shell scripts for man and info with the necessary commands, put them inside the app, and had Xboard open them when selected in the menu with osx's open command. Now everything in the help menu works as it should and I re-uploaded all 3 packages.

I thought about logos, whether I wanted to include them or not. Personally i think they look nice, and I'm sure others would like to do the same. Technically such files should go in a ~/Library/Application Support/Xboard/ folder. But there is no way to have xboard create such a folder or put logo files there for people. So was reluctant to set anything up and just let people do what they want. But It can be a bit of a challenge to setup, one would have to do research, and find out that xboard can now only read .png files, not the old formats it says in the manual.

So anyway to make things easy for people, I included in the dmg a logos folder for people to put their logos, plus a few examples like the winboard installer, and then had the xboard master conf point to that.

I'd like to see xboard to one day have a toggle in the General Options for displaying the logos like winboard, i.e. set logoSize either 0 or 100. I'm really not sure if any other value is all that useful. isn't 100x50 some sort of standard?

Standard sizes for logos are 100x50 or 130x65. But both WinBoard and XBoard would resize the logo to what is needed. Which would degrade the image quality a bit, as the logos are not SVG, but BMP (WinBoard) or PNG (XBoard) images.

I am a bit puzzled that the Crafty and Stockfish logo in your XBoard screenshot don't seem to fill all available space. I would have to check into that.

Logo's in XBoard are still a bit of a logistical problem. Windows engines typically install in their own folder, and WinBoard uses the convention that if there is a file logo.bmp in that folder, it uses it for the engine (with -autoLogo true). For humans or ICS it looks in the 'logos' folder of the install, for files USERNAME.bmp or ICSNAME.bmp. I am still considering to expand this to have folders logos/freechess.org/ and logos/chessclub.com/ where people could put files ICSHANDLE.bmp to have logos specific to their opponent on the ICS, rather than just see the ICS logo. (And if both players use WinBoard, they could automatically exchange logos through tell messages in the background.)

But in Linux engines are not stored with their files. Native Linux engines (when compliant) would store private files in directories like /usr/share/games/fruit/, and XBoard could be made to look there for logo.png files. It might not know the name of the engine package, however, which in the example is 'fruit', while the engine might have said in its 'myname' feature it is 'fruit 2.1'. (And MaxQi would come from the fairymax package, etc.)

Of course it could use a similar mechanism as WinBoard does for human logos, create a directory /usr/share/games/xboard/enginelogos/, and keep files ENGINENAME.png there, where ENGINENAME would be exactly what the engine reports in the 'myname' feature. (Or perhaps it should just use the engine command.) This is rather undesirable, however, as the logos reallyought to go with the engine, and are not XBoard specific. (Other GUIs should be able to use the same logos.)

It would be good if there was some general Linux standard for installing engines using a standard protocol, e.g. /usr/share/games/uci where engines could announce their presence by installing a small info file and a logo, so that GUIs could scan the directories for the protocols they support, (e.g. in their 'install engine' dialog).

I am a bit puzzled that the Crafty and Stockfish logo in your XBoard screenshot don't seem to fill all available space. I would have to check into that.

Yah, seems to be how GTK handles it. It centers the logo in the given space which expands as you drag the board horizontally. In xaw it leaves a bunch of space underneath the logo if the clock font is large, it doesn't seem to expand with the clock properly or center. I am using -logoSize 100. Perhaps I should try logos at 130x65 size, see how it compares.
[edit]
If I try logoSize 130 then the clock takes over the whole space. Not sure whats going on there
[/edit}

Linux really is an odd system the way it handles files of programs. As a windows/osx user it took me getting use too how you wouldn't keep supporting files in the same place as you do the executable. You wouldn't put raster image files in the /usr/local/games directory. It is a lot more manageable to make a folder somewhere in the home directory as you don't have permissions anywhere else. So your current system works well for that environment. OSX however always seems like some sort of compromise between linux and windows. Unfortunately one of the quirks of the Xboard.app is it doesn't know PATH unless I open the launching script in the terminal. This isn't a bug in xboard but either the launching script or a quirk with OSX itself. But this is ok as I don't intend the user to ever touch the terminal anyway. (hence all the load ICS bash scripts) The browse menu inside the Load Engine, works very well for this. (Though is there some way to get the engine directory box to derive the directory from the engine command box like winboard? It always feels redundant.) So anyway the whole convention is blown out of the water.

The other option I thought about putting the logos inside the app, but again, I'd have to tell them how to set it up. I think it's best to try to make it all obvious. So you can see how it works at a glance. It's a good thing xboard derives the logos from the title of the executable, and not the name it was compiled as, or that goal be much more challenging.

-------------

You mention freechess.org/chessclub.com folders. I think I should point out that I found timeseal and timestamp won't connect unless you use the ip adress of freechess/chessclub as the icshost and not the domain name. I get a permission denied error. It's the same way in linux.

Well I finally was able to compile xboard against the 10.6.sdk which makes it work on OSX 10.6 and later.

There was a bit of a catch in the process. Apparently in /gtk/xboard.c the function strndup() isn't available in 10.6. Apparently it was added in OS10.7 and up. So to get around this I found this hack that defined strndup for the compiler. I put the patch labeled xboard-GTK-OSX10.6fix.patch in the src folder inside every app bundle.

Code: Select all

diff -uprN ./xboard-4.7.2-patched/gtk/xboard.c ./xboard-4.7-2/gtk/xboard.c
--- ./xboard-4.7.2-patched/gtk/xboard.c   2013-08-29 01:21:28.000000000 -0400
+++ ./xboard-4.7-2/gtk/xboard.c   2013-12-06 21:42:08.000000000 -0500
@@ -175,6 +175,32 @@ extern char *getenv();
 #define usleep(t)   _sleep2(((t)+500)/1000)
 #endif
 
+#ifndef NODE_STRNDUP_H
+#define NODE_STRNDUP_H
+
+inline size_t
+strnlen(const char *s, size_t len) {
+size_t i;
+
+for(i = 0; i < len && s[i]; i++)
+;
+return i;
+};
+
+inline char *
+strndup(const char *old, size_t sz) {
+size_t len = strnlen (old, sz);
+char *t = (char *)malloc(len + 1);
+
+if (t != NULL) {
+memcpy (t, old, len);
+t[len] = '\0';
+}
+return t;
+};
+
+#endif /* NODE_STRNDUP_H */
+
 #ifdef ENABLE_NLS
 # define  _(s) gettext (s)
 # define N_(s) gettext_noop (s)


Gave the icons a little care and added in a separate one for winboard. Only now it occurs to me, I should call it Wineboard.

Finally was able to move the menubar up into the native mac osx menubar, thus leaving a little more room for the board, plus make it look like the mac app it is! A huge thank-you to HGM for all his help with this. It has been a couple days of his time to get this right. Of course, without him xboard would still be at 4.2.7 and more then a decade into obscurity. So thanks for that too!

Also I decided to nix the new icons and go with the old ones as the new ones just didn't mipmap very well.

Another update to the 4.7.2 app. Some improvements to the OSX integration. We managed to associate xboard with pgn, .trn, xop and fen files through the OS (Game Notation, Tournament, Option and Position files respectively). Also we got the OS to open these files through XBoard either though drag and drop or clicking on them directly. If XBoard is already open, it will just launch another instance and do it there. Huge thanks to HGM for all his effort as we just hit one issue after another. Also thanks to Alun Bestor, author of the dos emulator Boxer, who helped me with the info.plist modification (The man is a genius when it comes to OSX). Also a few bugfixes too that are in the main branch that we caught along the way.

Finally 4.7.3 app is out.
It took quite a bit of doing, but, thanks to hgm's help, we finally managed to get xboard.app to be more intelligent with how it finds its data files by making xboard know it's own bundle directory for commands. with "~~/" (doesn't work in the menus)

Before I was using a relative directory system, where the working directory was inside the app for everything to relate too. This had a negative side effect where many engines, and xboard even, would save files inside the app as oppose to the home directory. Which is no good.

Unfortunately this once again breaks everyone's 4.7.2 user conf file in ~/Library/Preferences/Xboard.conf, because the old settings will interfere with the new ones. As such, people should delete it and let xboard build a new one. Hopefully this wont happen again.

Hey there!

Currently, on 4.7.3 (Linux and Windows versions), when using a custom engine it works flawlessly.

I have spotted an issue with the Mac version. Whenever running XBoard like this:

Code: Select all

/Applications/XBoard.app/Contents/MacOS/XBoard -debug -fd $(pwd) -fcp ./MyCustomEngine

XBoard is normally started, then lots of other XBoard processes which open and close right after are started.

Do you have any idea how to fix this?

Note: The command is run from the executable directory.

This is the XBoard MacOSX version, not WinBoard.

I know what causes it, and it's already on a huge list of things to fix. It comes from the code meant to be-able to launch multiple xboards in osx when the user wants it, but something got borked with multiple signals and we get a bazillion xboards instead of two. We had fixed it before I posted, but now it rears it's ugly head again. And I have no idea why. Not being a coder I have no idea how to fix it, and have to wait till hgm can get around to it, but he is already boged down in other areas. Rest assured, once we do, I'll upload a new version.

In the mean time, what you can do is launch xboard with the -debug flag and select your custom engine in the Engine -> Load New First Engine ... dialog to open your custom engine.

Hey!

Thanks for the response. While that seems like a good workaround, I already installed XBoard from Homebrew for now since this thing is a must-have automation for me. I'll just wait for a future bundle.