XBoard for Mac: Zippy problems

[sje]

It suffices to set the sound program to an empty string. Then their will be no sounds and no bogus invocations (and can be done through the Sound Options menu dialog). Is that not good enough?

There is nothing in the dialog (from the latest Debian xboard package) mentioning setting that field blank. Also, no check box, which is what's really needed.

In the case of any auxiliary program, XBoard should check to see if the program/script file exists and is executable, before accepting it as a choice.

[hgm]

There is nothing in the dialog (from the latest Debian xboard package) mentioning setting that field blank. Also, no check box, which is what's really needed.

Well, isn't it obvious that when you don't specify any sound-player program, you won't have any sounds? What would you have expected XBoard to do if the sound program was specified as an empty string? Most dialogs have the property that if you don't specify a file for something, that something will not happen. E.g. board textures, piece-image directory, PGN file with opening lines or FEN file with opening positions for a match...

A checkbox is is useful for temporarily disabling a feature that required a very long text string (usually a path name) to activate, without losing the text and having to retype it when you want to enable it again. (E.g. for the opening book or the board textures.) For something like "aplay" retyping it is hardly any work, and indiscriminately adding new control elements in dialogs and command-line options to save them in the persistence file also has drawbacks. And I would not expect people wanting to change their sound settings all the time. Temporarily disabling sounds you normally want can usually be done through the OS already.

In the case of any auxiliary program, XBoard should check to see if the program/script file exists and is executable, before accepting it as a choice.

Isn't that a bit pedantic / patronizing? The system will warn you if you don't have it installed, and then you can install it. If you are really worried whether you got it right, you can select a "Try-Out Sound" and press 'Play' for it to test if everything works before you close the dialog.

[JoshPettus]

Yup, 'afplay' is what I configured in the osx app.

[sje]

In the case of any auxiliary program, XBoard should check to see if the program/script file exists and is executable, before accepting it as a choice.

Isn't that a bit pedantic / patronizing? The system will warn you if you don't have it installed, and then you can install it. If you are really worried whether you got it right, you can select a "Try-Out Sound" and press 'Play' for it to test if everything works before you close the dialog.

One problem here is that if the sound player is missing or messed up, but this isn't caught at dialog time, then the user is reminded of it on each and every move in each game in a match. The match must be aborted then restarted. This is not the best way of doing things.

[sje]

Gosh, it worked.

Well, except that I had to fiddle with the various options like killing the sound.

You can edit the options to remove the "aplay" (you should try to type that word in Safari). Or you can just make an empty file that is executable, and give it that name, to get rid of the incessant complaints about that executable being missing.

Perhaps I spoke too soon.

For some reason, all of the centisecond data output by xboard (from macports) is being rounded to the nearest 100 centiseconds.

[bob]

Or you can just make an empty file that is executable, and give it that name, to get rid of the incessant complaints about that executable being missing.

Which is what I'd done before; a noop aplay.

But the better solution is to have the XBoard dialog include a master switch that can disable all sound and all bogus invocations of a sound playing program.

There's a menu item to turn this off. I just had not poked around very much but found the menu way to get rid of it later.

[sje]

There's a menu item to turn this off. I just had not poked around very much but found the menu way to get rid of it later.

This I do not see on the Debian xboard version (4.6.2, says the man page).

----

There is an aplay program on a Raspberry Pi, but it won't work until some magical sound driver activation is performed first.

[sje]

MacPorts: port Unix applications to Mac OS/X
Seven versions for Mac OS/X 10.4 Tiger to OS/X 10.10 Yosemite
https://www.macports.org/
https://distfiles.macports.org/MacPorts ... semite.pkg

XQuartz: X Windows server for recent versions of Mac OS/X
Single version supports OS/X 10.6 Snow Leopard to OS/X 10.10 Yosemite.
http://xquartz.macosforge.org/
http://xquartz.macosforge.org/downloads ... -2.7.7.dmg

I installed both MacPorts and XQuartz on a year 2010 iMac (3.2 GHz Core i3 dual core, 16 GiB + OS/X 10.10 Yosemite), and then installed xboard via MacPorts. Everything went smoothly.

Before using XQuartz for the first time, it's recommended to log out or reboot first so that certain XQuartz secondary information can worm its way through the system.

I note that starting XQuartz implicitly by first starting xboard can be a bit clunky as XQuartz needs some time to itself to pull its brains together. Better is to start XQuartz explicitly first and maybe wait a few seconds before invoking xboard.

Perhaps the above could be included in the xboard documentation for Mac users, and particularly for Mac users who want to connect to an ICS via xboard with their own engine.

On my 2006 Mac Pro running OS/X 10.7 Lion, I use Apple's X11.app instead of XQuartz, but I might change this as the X11.app is no longer supported.

[hgm]

Perhaps the above could be included in the xboard documentation for Mac users, and particularly for Mac users who want to connect to an ICS via xboard with their own engine.

Which version of XBoard is this? The X11 build of XBoard can be considered obsolete. I am not sure whether the GTK build needs XQuartz. The Gtkosx build certainly does not. It doesn't make much sense starting to add stuff specifically aimed at using obsolete versions in the documentation. If there are problems remaining in the Gtkosx build as supplied in the App, we should fix those, rather than starting to recommend an obsolete version.

[sje]

Perhaps the above could be included in the xboard documentation for Mac users, and particularly for Mac users who want to connect to an ICS via xboard with their own engine.

Which version of XBoard is this? The X11 build of XBoard can be considered obsolete. I am not sure whether the GTK build needs XQuartz. The Gtkosx build certainly does not. It doesn't make much sense starting to add stuff specifically aimed at using obsolete versions in the documentation. If there are problems remaining in the Gtkosx build as supplied in the App, we should fix those, rather than starting to recommend an obsolete version.

The xboard in use is the one distributed by MacPorts which is version 4.7.3. This is only slightly behind version 4.8.0-2 which is distributed by Debian. Both are built for X11. Are these obsolete? If so, then someone should report this to MacPorts and Debian.

BTW, there is a slight problem with the Debian xboard package: https://lintian.debian.org/tags/source- ... -file.html

The Gtkosx xboard has problems, particularly for Mac users who are trying to connect an engine to an ICS. These problems are unlikely to be resolved until there is sufficient testing by an xboard maintainer and documenter who has a Mac and who is trying to connect an engine to an ICS. In the interim, end users would save much time if the suggested addendum were added to the xboard documentation.