Sorry It took so long before I could try it. I take back everything I said. This is beautiful!
I'm having a problem with the app bundle however. The help clicks will work just so long as the Xboard.app itself resides in the xboard source folder. Once I move it, it can no longer find it. Apparently it looks only in the compiled spot for the file. Once that is set, the app can't move. Can we do an #ifdef OSXAPP to search for the man file relative to my datadir? should be datadir/../man/man6/xboard.6. I know it's back to the kludge but I'm not sure what else to do.
Another thing regarding engine man pages. On mac especially I don't usually bother installing the engine on the unix system. Can we also have it look in the engine directory as a place of last resort?
To get the XBoard manual it now looks in MANDIR/man6/xboard.6 . MANDIR should have been configured taking account of the OSX option.
But I now vaguely remember we did some dynamic stuff for DATADIR in the OSX App, where we redefined it as a variable instead of a constant. So perhaps we should define the manFile location relative to DATADIR. Initially I had that, but then we ran in the discrepancy that Debian needed ../../ and OSX only ../ because it did not have "games" in the path. And it would be bad practice to assume a fixed relation between the data files of an application and its manual.
Perhaps we should treat MANDIR exactly the same as DATADIR? I.e. redefine it for the OSX App as the variable manDir, and then fill that variable in the piece of OSX-specific code at the start of xboard.c. Probably deriving it from dataDir. Then the Linux build can simply stick to the MANDIR as supplied by ./configure. I would have to change the code in DisplayHelp() to be resistent to MANDIR being a variable, i.e. not write
I suppose we could look in other places for the engine manual as well. This area is a bit flaky anyway; the current code assumes that the engine command would be a single word, equal to the name of the manual. This would work for fairymax, crafty, gnuchess. I am not even sure it would work for fruit; it might try to read the polyglot manual. It would not work for maxqi, which is described in the fairymax manual. And fairymax' manual is currently gzipped (for no good reason; I just mimicked some example). And even if it were not, the format is currently not such that the help function would find anything in it.
if(option[i].target || dlgNr != ErrorDlg && option[i].name && !strchr(option[i].name, '\n')) { // allow user to specify event handler for button presses
This handles attachment of a click handler to a Label Option. Problem apparently is that in the Edit dialog option.name can be a NULL pointer, which then makes strchr segfault. If I test first for option.name being non-null, like above, the crash disappears.
A bit weird; this dialog does not even seem to have Label options in it, let alone Labels without name.
[Edit] Oh, I see. There actually is a Label above the text memo in that dialog. It is only used to display a message in cmail mode, otherwise a NULL pointer is passed as message to TagsPopUp. So that explains it. It is arguably a bug that the Label appears in the dialog at all, if there was no message to display.
Last edited by hgm on Sat Mar 12, 2016 2:26 pm, edited 1 time in total.
Hmm I supposes the are all classified as games, either that or .man....But then crafty's is .hlp... I have no idea. I guess .6 is as good a standard as any.
hgm wrote:I am experimenting with a new feature in XBoard, and would like to have some feedback from users to see if it is useful. The idea is to make XBoard's manual file more accessible. Almost noone takes the trouble to read manual files, and, quite frankly, XBoard as grown so extensive, and consequently its man page so long, that I cannot really blame them.
So the idea is to make right-clicking on the names of controls in menu dialogs, or on the menu items themselves, provide direct access to the relevant paragraph in the manual, displaying the text in a popup window. In the experimental implementation I just have it scan the manual file for a header line containing the same text as written next to the dialog control, and as the item headers in the manual usually equal the name of the control or menu item this already works for the majority of cases.
If we decide to go on with this it would just be a matter of re-writing the manual (organizing it more systematically) so that it works in all cases. A nice enhancement could be to apply the lookup of controls clicked in the Engine Settings dialogs in the manual page of the corresponding engine, rather than in XBoard's own manual page.
The XBoard version that does this can be found in the 'help' branch of my on-line source repository:
Only the GTK build (which should be the default build in this version) does this.
HG - just noticed that it's impossible to turn off the 50 move full in xboard. I can changed it to 100, but always rules a draw at move 50. I have a cursed win that goes for 485 ply and would like to see the entire pv.
Does XBoard adjudicate that, or does the engine claim it? XBoard has no way to prevent an engine from claiming a draw. If the engine does not want to play, it does not want to play. We could forfeit it for that, but that is probably also not what you want. (And a bit unfair to the engine.)
In other words, the ruleMoves option is an option that controls adjudication by XBoard. The engine doesn't know anything about it. For that, you would need an engine option to set the rule moves. (Fairy-Max actually does have such an option!)
Hmm, really strange. I just compiled from the latest in the help branch. It still works in the folder I compiled and built the app bundle, but as soon as I move the app it still doesn't find the man file. (Moving it back makes it work again) did MANFILE not get undefined and reassigned? The code looks like it should.
And one more quirk, when it does work, you must hit OK on the help dialog. If you close the dialog via the closing the window, you can't close the options menu underneath. Just a guess, but it's as if it's still waiting for input from the closed help dialog.