OSX XBoard/WinBoard.app 4.7.3 Release Thread

[H.G.Muller]

Indeed, I guess the sounds directory is also a 'never touch' option. The sounds dialog was one of the first I added to XBoard, and I was so happy that options could be set through the GUI that I added controls for every option I could think of. There is very little reason to change the sound directory, because it is possible to add your own sounds anyway, through browsing to .wav files. It is just that they would never become standard sounds that would appear in the comboboxes, you would have to supply their pathname explicitly for every event you want to assigne them to. (But why would you want to couple the same sound to different events?)

[Josh Pettus]

I just tried the last commit and got

Code: Select all

  CC       gtk/xboard.o
In file included from /usr/include/stdio.h:490:0,
                 from gtk/xboard.c:56:
gtk/xboard.c: In function 'LoadLogo':
gtk/xboard.c:2238:20: error: 'MDG_SIZ' undeclared (first use in this function)
      snprintf(buf, MDG_SIZ, "%s/logo.png", appData.directory[n]);
                    ^
gtk/xboard.c:2238:20: note: each undeclared identifier is reported only once for each function it appears in
make[2]: *** [gtk/xboard.o] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2

while building.

Also just for convenience, I'd like to list the other things we discussed.

1. Add option in Board menu to choose -logoDir
2. Hardcode xboard to always search DATADIR\Contents\Resources\share\xboard\logos independent of -logoDir
3. Hardcode xboard to always search DATADIR\Contents\Resources\share\xboard\sounds independent of -soundDirectory

I think that's it?

[H.G.Muller]

Oops, typo. Should have been MSG_SIZ.

As for the other stuff, I think that is overdoing it a bit. -soundDirectory should simply be configured to DATADIR\Contents\Resources\share\xboard\sounds in the xboard.conf, and I see no valid reason for a user to change it. (But if an occasional user can think of one, he can still do it through the menus, and he must supply is own sounds for everything.) The -soundDirectory is not really generally applicable, as the names and filenames of the sounds in the comboboxes for the various events are hardcoded in XBoard. If the user would put a sound file with a different name in the -soundDirectory, it would still not appear in the menu. If anything would have to change, it would be removing the sound-directory control from the Sound Options dialog...

For the logos I think it would be better to just do put the fairymax and fruit executables in separate directories, and put their logos with them as logo.png. And configure -logoDir not at all, or as some standard place outside of the bundle (e.g. /usr/share/games/plugins/logos/ , or whatever other place we will define as the Mac standard for storing logos for game plugins).

[Josh Pettus]

You're probably right about the sound dir. But with the logo's you are forgetting about ICS logos, and there isn't really a standard place for logos to be defined anyway. It could basically be anywhere. I don't know... We still have the stuff predefined by the app for basic use. (fairymax, fruit, FICS, ICC, your sever.), and I think it would be best if that stuff were never broken while freeing people to move the logo dir to wherever they want. (perhaps they have a personal logo they want to put in.) But it's your call.

Actually that's not entirely true. There is an official Apple-to-spec place for xboard.app to store all axillary files related to it. ~/Library/Application Support/Xboard. But that is so end-user unfriendly I would never consider it. (~/Library is hidden with no easy way to make it visible) Which leaves me either inside the app or in a user defined place. And practically speaking, inside the app isn't meant for people to mess with.

If I move fairymax, we would have to change the hard coded place to find it, but that's no biggie.

[H.G.Muller]

You're probably right about the sound dir. But with the logo's you are forgetting about ICS logos, and there isn't really a standard place for logos to be defined anyway.

Yes, there is, I just defined it (/usr/share/games/plugins/logos). If that is not satisfactory for OS X, we should define another one for that is. And it might actually work best for OS X to adopt as primary standard that logos should go in the engine directory, so that no dedicated logo directory is needed. Note that engine logos are not really connected with XBoard in any way; they can be used by any GUI. So ~/Library/Application Support/XBoard would definitely not be the proper place.

You are right about the ICS logos, though; this is also a problem on Linux, as ICS are not installed on the machines in any package. So if there are to be ICS logos, they must come with the package of the ICS client, i.e. XBoard. But that makes it logical to place them in XBoard's private data, i.e. /usr/share/games/xboard/logos/FICS.png etc. This could mean duplication of data if there are different ICS clients that each want to use logos, but as there are only a handful of ICS and logo files are small, that isn't really something worth worrying about.

XBoard distinguishes between ICS and engine anyway, for what exactly it does on -autoLogo. So for engines it can look in the engine dir and the system's default logo folder (which the packager can configure through the -logoDir option to be suitable to the OS he packages for), and for ICS (where there is no equivalent for the engine dir) it would look in the DATADIR of XBoard (which would normaly be adapted to the distro by the ./configure process, but in the case of OS X would be mapped inside the bundle through the bundle_path kludge we already use to determine it at run time). And as a second option it could then be made to look in the -logoDir, just in case the user wanted to do something non-standard, and has redefined it (and deleted the FICS and ICC logos in the bundle).

This does leave the problem of handle-specific ICS logos, but I think at the moment XBoard does not support those at all. I think this concept only makes sense if we also have an -autoTradeLogos option, which would send players each other's logos through the ICS. (For how else could such logos be distributed?) That means that XBoard should be able to store the received logos, which sort of rules out standard system places where you have to be superuser to write. It seems that the Debian standard to solve such problems is to have a 3-step hierarchy for looking for files: /usr/share/games/xboard/ (for standard packages), /usr/local/share/games/xboard/ (for adminitrator installs from source) and ~/.xboard/ (for installs by users without admin rights), searched in the reverse order. I guess the ~/.xboard/ is similar to OS X' ~/Library/Application Support/XBoard; it is also hidden. In this case the logos are only weakly connected with XBoard, though. So it would probably make more sense to just store them in ~/icslogos/<icsname>/<playername>.png, where '~/icslogos' could be made a user-configurable option distinct from the -logoDir for engines (although I am not sure how much sense that makes).

[Josh Pettus]

With OSX, lets keep the logos with the engine. As a rule it's not a good idea for the a program to throw resource files deep into the system, the Users/Home directory is used for that. I guess ~/icslogos would be ok for ICS traded logos, if they were to ever adopt that. Right now, xboard is the only GUI that makes use of them on OSX. The competition is basically only SCID for Mac, and the Stockfish GUI which is only meant for stockfish...(We could use more love...)

If xboard is expected to supply the ICS logo itself, then I guess that HAS to be inside the bundle. DATADIR/Contents/share/resources/xboard/logos/FICS.png. If -logoDir would never be touched by a user, then I guess this is ok to use for the app to point to it.

[Josh Pettus]

Hi HGM, It's a real shame you don't have a mac, because all of our hard work really shines. It looks fantastic, and I can only imagine how clean It all looks on a high-res retina display. I think it beats winboard. Thanks again for all your help. I've been wanting a proper xboard .app for a long time, and now we have it!

Arun, has been kindly helping me with my Gettext woes once again. It will probably take a bit of time as he is quite busy. But in anticipation of or success, how would be the best way for us to point gettext to the in-app locale folder?

I think it would have to be

DATADIR/Contents/Resources/share/locale

[H.G.Muller]

I must admit that the XBoard GTK version was really the first Xboard version that gave me the authentic WinBoard feeling. I am really happy it works on OS X now; I had always imagined that to pull that off would require a complete rewrite of the front-end in 'Objective C', or something equally scary. As it turned out we only had to add some 50 lines of __APPLE__-dedicated code. Now only Android is left to do...

Unfortunately I know very little about gettext, and could not get it running on my new laptop until yesterday, with Arun's help.

Now that XBoard 4.8.0 will support Chu Shogi, could you add HaChu to the XBoard Shogi app? Too bad the standard edition of XBoard does not support Dai Shogi yet. (Even the WinBoard Alien Edition only supports Dai Shogi and larger variants so-so: there is an awkward notation problem when the number of unpromoted piece types rises above 26.) But it would still be worth it for Sho Shogi and Chu Shogi, I think.

I also made a version of Shokidoki that supports Tori Shogi, but I only hard-coded the rules of Tori Shogi in the Alien Edition. And Shokidoki also does not do legality checking on the input moves, it just accepts anything, so that would make it quite hard to use it with legality-checking off. So I really don't know if there is any point in upgrading that.

I could equip Shokidoki with support for the highlight protocol, or at least make it do legality checking. But perhaps it would be better to extend XBoard protocol with commands that would allow the engine to reconfigure its move generator, by sending a description of how every non-standard piece moves.

[Josh Pettus]

Android would be a challenge for sure. For that, I fear, you may need a whole new front end. I wonder if QT would be the way to go or the native toolkit. Google says QT can do SVG stuff.

I would definitely will be updating the Shogi and Xiangqi apps. Particularly as they suffer all those bugs we just fixed, and the better management of SVGs is a must! Before I had to combine all the missing pieces from default with the kanji and use pid to point to that. I'll be sure to update Chu Shogi.

If you want you can email me a coded zip of Shokidoki and I'd be happy to compile it again, even if it doesn't do much of anything. The version I have is Shokidoki ICGA 2013. Also HaQiKid if you messed with it recently. I have HaQiKiD 1.7d ana.

[H.G.Muller]

The HaQiKi D project has been dormant for years. Last time I touched it was in 2010, when I tried to make it SMP, and that was a complete failure (it just slowed down if you ran it with multiple CPUs), so I discarded that branch.

Perhaps I should still try to squeeze a simplified version of the engine->GUI 'piece' command into XBoard 4.8, without the capability to handle multi-leg moves, checkers, atomic explosions, Ultima pieces. There is no such weirdness in Tori Shogi, just standard moves in non-standard combinations. For many of the Fairy-Max variants that only can be played with legality testing off holds the same.

As for the Android front-end, you are right about the complete rewrite, and this has always been the plan. Most of my work on the XBoard front-end was inspired by this, in order to separate the existing code into a minimal platform-dependent part and platform-independent code and data pertaining the front-end design (like tables of what kind of control elements should be in which dialog, etc.) This way the amount of code that would have to be rewritten has shrunk by at least a factor 3 compared to the original XBoard Xaw front-end. Basically there is only xboard.c and xoptions.c now that would have to be rewritten from scratch. Of course if we really would want XBoard to be suitable for running on a phone, there are some design issues. (A separate board and engine-output window might not be such a good idea there.)

[Josh Pettus]

Hi HGM,

I remember now that you said your email didn't receive mail?

Just in case, compiled shokidoki but both GCC 4.8 and Clang ignore the -s command due to "obsoleteness" How did we strip out the executable again? I lost the old email, I'm afraid.