XBoard interactive help

[hgm]

I pushed a patch now that obtains the path to the man file dynamically, by calling "man -w xboard" or "man -w ENGINENAME". It doesn't use the MANDIR anymore. (Although I did not yet delete the code for setting it.) The advantage is that this finds both plain text and gzipped files (which I then unzip). And that it also finds the fairymax manual when the engine is maxqi.

I wonder if this also works on OSX. (The fairymax manual does not explicitly list the interactive options, though, so you won't get any useful help from there. But the fact that you get a popup at all, even if it just says "No help on ...", shows it could locate the manual.)

[JoshPettus]

I gave it try. Looks like it still works for the app, and hangs slightly the first time you run it (Am I correct and assuming it is searching the filesystem/database for the file?).
I'm a little surprised as the man file isn't in the normal man location, and changes when I move the app...
Not sure what to do about engines you havn't installed via the script though, strange it doesn't find the man page then.

Btw I also managed to get the translations that came in today on savannah master. I'll be sure to keep up with them.

[hgm]

I suppose this is the time needed to execute the "man -w xboard" command. For XBoard it remembers the results for the entire session. But if that takes measurable time it would be a bit annoying to do it for every help click on the engine settings. So I guess I should have it remember the name of the engine man file as well, plus the name of the engine used in the "man -w" command to obtain it. Then it can only run a new "man -w" command when the name has changed.

Are you sure it finds the man file in the App, and not one that is accidentally left in the standard place? How do you make the 'Man XBoard' item in the Help menu work in the face of the variable location of the man file?

[JoshPettus]

I asked myself the same question. I checked in user /usr/local/man and there indeed was an old xboard.6 man in there. But I removed it and the app still worked.
I tried looking elsewhere, to be sure, and found nothing. I then tried the locate command, and sure enough, apple didn't have it setup by default. The database wasn't even created. So I'm really wondering how is it that man is able to find the correct manfile myself..

The time to search for the man file is only a couple seconds at the start of the app. After that, it pops up instantly. I have yet to get it to work for the engine settings yet.

To get at the man and info page before, I always used the value of dataDir as it was the only directory we had that would dynamically update to point to inside the app. Which is fine as it is not like there is any variation for the app bundle.

gtk/xboard.c

Code: Select all

1976     snprintf(buf, MSG_SIZ, "osascript -e 'tell application \"Terminal\"' -e 'activate' -e 'do script \"man %s/../man/man6/xboard.6\"' -e 'end tell'", dataDir);

[edit]

It occurs to me, as far as the app is concerned "xboard -w man" shouldn't work at all. xboard executable in the app isn't part of Path. When I type it in it tries to use the separate xboard install 4.2.7 install i have on system (for jokes). But that says (because I deleted the man page)
"No manual entry for xboard"

It's possible the env set by the gtk launching script is making it work, but when I point man -w 'gtkLaunchScript' it points to the wrong place for manDir, which is why it doesn't work when I click on that script directly). And yet it all magically works for the app... You must be a wizard.

So you must have some real black magic at work right now.

[hgm]

What happens when you type "man -w xboard" (or "man xboard") from a terminal?

[JoshPettus]

You and I thought the same thing at the same time.

Answer:Beats me. I know the answer i get from the terminal (which is it shouldn't work at all), but that is clearly not the answer the app somehow gets. I got to make a few changes and recompile...

[JoshPettus]

To be on the safe side, I believe it best to just use our old system for the osx app. At least that's predictable, and not dependent on the alignment of the planets...

[hgm]

Note that you said "xboard -w man" above where it should have been "man -w xboard", and I am not sure it was just a typo here.

Can you add the DisplayNote call here in dialogs.c:

Code: Select all

    if(!xboardMan) {
	xboardMan = BufferCommandOutput("man -w xboard", MSG_SIZ); // obtain path to XBoard's man file
	if(xboardMan) xboardMan[strlen(xboardMan)-1] = NULLCHAR;   // strip off traling linefeed
DisplayNote(xboardMan);
    }

So that we can see with certainty which man file it actually uses? If that same command would not work from a terminal, the only thing I can think off is that it is because you are in a different directory as where XBoard would be when it forks off this command.

It would be possible to make xboardMan a global variable, and initialize it in the OSXAPP part at the top of main() to a resource-path-derived filename. For the App, after all, we do not have to take account of the possibility that it can be a .gz or a .bz file; we know what it is. When xboardMan is non-NULL, the code in DisplayHelp will not try to obtain it.

[JoshPettus]

oops that was a typo... Too early in the morning. That wasn't what I used on the system

Thanks, that's a lot simpler then what I was failing at
It was finding the correct man file. But like I said, before, I have no idea why. (partially because I'm not sure exactly how man's searching works). The gtklaunch script changes what is in path for xboard app before runtime. I tried setting up a similar environment and working directory to emulate the results, but no luck. There could very well be a variable I can't account for that could effect how it searches for xboard man. So I think using the search as a last resort might be ideal.

[hgm]

Well, in the App there never is any uncertainty where the XBoard man file is. So I guess in that case we simply hard-code it. For the engine manuals it is a different matter, however. Do you get any response when you try a help-click in the Engine Settings dialog when Fairy-Max is loaded? (The Fairy-Max manual is not yet such that you could get any sensible help, but at least you should get the "No help on" note popup when it can find the man file.)