Indeed, this is odd, and unintended. Probably it should be considered an XBoard bug.
The problem is that OS X sends this OpenFile signal sometimes (but not always) to the first and only instance of an application, when it starts up. This seems to depend on the way it is launched. The application is then simply started with initially just a plain "xboard" as the command line, without any arguments. An OpenFile signal is then sent to this instance after it started, together with the full command line.
The problem is that this situation is difficult to distinguish from one where the user would first start an XBoard instance that indeed did not have any arguments, and some time later tries to start another instance with arguments, which then is replaced by OS X to sending the OpenFile signal to the already-running instance. In this latter case the already-running instance should fork off a second XBoard, as that is what the user asked, but in the former case it was all due to a single invocation of XBoard with arguments, and the reception of the OpenFile signal should be used only to redefine the arguments of the existing instance. I assume XBoard simehow confuses the two cases here.
Perhaps we have been approaching this the wrong way from the start, and should have always started the XBoard binary from an "open -n" command in a script, so that it never needs to fork off a new instance in response to an OpenFile signal, but can always assume this signal is just supplying its own arguments.
I can start one tournament instance by doubleclicking the tourney file - but after that I suppose I have to a command line start any additional instances?
In principle you can double-click a tourney file as often as you want. Each double-click should start a new XBoard running on that tournament. The .trn mime type is associated with XBoard in the desktop manager through the command "xboard -mm -tf XXX.trn". (In fact this does the same as "xboard XXX.trn", as mentioning just a filename without a flag argument to specify what it was for makes XBoard automatically add the flag arguments useful for a file of that type, "-mm -tf" for .trn files, "-lpf" for .fen files, etc.) Clicking the file is just a method to generate that particular command, and it should not matter how you generated it.
MikeB wrote:Both of these do not work:
Code: Select all
"Fruit"-fd /applications/fruit -fcp "./fruit" -fUCI
"~~/../../bin/fruit" -fcp "./fruit" -fUCI
I don't know if this is just a typo in the forum post, but note that both of these lines seem defective. In the first there should be a space before -fd. (Not sure if this can be fatal, though.) And it would try to run a version of Fruit not in XBoard App bundle, at /applications/fruit/fruit. (You could check if there indeed exists a file of that name.)
The second line should have an initial -fd, and would then try to run the fruit binary that is included in the App bundle. ("~~" stands for the installation path of the bundle.)
Proper operation of the -fUCI option is dependent on the value of the option -adapterCommand. Which in this case should refer to the Polyglot inside the XBoard App bundle, like
polyglot -noini -ec "%fcp" -ed "%fd", containing the instruction to pass the XBoard -fcp and -fd argument to it. If this option is not set, or would not specify a working command to invoke Polyglot, it would break the -fUCI option, which is pretty agnostic in itself, and just substitutes the -fcp value for what the -adapterCommand says, after replacing all %xxx in the latter by the value of -xxx.
