OSX Xboard 4.7.2 .app

[hgm]

char * homedir = getenv( "HOME");

Oh, I did not know that trick. Is that reliable?

I used:

Code: Select all

getpwuid(getuid())->pw_dir

Which is not terribly complicated either.

[JoshPettus]

I take it that that is more direct?

[JoshPettus]

I take it that that is more direct?

after some searching, and I'm just guessing here, If that works what about something like

Code: Select all

char * underscore = getenv("_"); 

to find the executable path?

[JoshPettus]

eh never mind, I doubt that that would work as it's a BASH trick. I suppose If I really wanted to do that we would have to some more OSX code and just do the call that's in the gtkosxintegration lib and set it to a character.

[hgm]

I am not sure why you are not happy with the current situation, where the character for the install directory is '.', so that you can use releative paths to define things from the install directory, even when you don't know exactly what that is / will be. In WinBoard, this is also how it works: WinBoard sets the current directory to its intallation directory at startup, and in the standard install I specified all engine directories relative to it.

(Problem is that in Windows this doen't always seem to work, and WinBoard's idea of current directory sometimes seems to change by something done in a completely unrelated task (like using the file-browse dialog there), after which WinBoard cannot find any of its pre-installed engines anymore, until you use the file-browse dialog in WinBoard itself again, to browse something in the WinBoard forum. But that seems to be a Windows problem.

[JoshPettus]

Couple reasons. First, cmail, and any program like it that wants to save files in a specific spot, change the working directory breaking everything xboard uses inside the app. Not major, but I'd still like to play with cmail. As it still does what it's suppose to do. (amazingly enough)

And second of all, and far more of an issue, if you go to the match menu and try to save a tournament file or a save file. You must put in the directory where it's going to save. if you just type a name it won't save in the default working directory which is the home folder, instead it will save the file inside the app, which is not good. Particularly as the default for the tournament file is just a generated name expected to save in the homefolder

[JoshPettus]

You have to remember that an app is really a folder with a specific internal structure and treated by the OS like an executable, at least as far as the user can tell. The install directory is a place most people won't see, unless they right click on the app and select view contents. I could change the working directory to be the first directory outside of the app, but that would be ugly all around and probably hit permissions issues.

[hgm]

OK, so you need to indicate files in the directory from which the user started (e.g. tourneyFile, saveGameFile), distinct from a standard place where XBoard looks for its own support files (textures, pieces, engines).

But there already are two such mechanisms: '.' and '~~'. It seems to me you should use ~~ for the root directory of the installed app. In the Linux version ~~ indicates something like /usr/share/games/xboard, supplied by the configure process through a -DDATADIR compile flag. But on OS X you would not use such a place with a fixed name, but would want to decide on it at run time, dependning on where the user installed the app.

This should be easy to implement, by storing the name in memory as initialized data

Code: Select all

char datadir[MSG_SIZ] = DATADIR;

and then let the code in args.h that interprets ~~ use the variable datadir rather than the constant DATADIR to build the actual path name. The OS X initialization code in main() could then request the app's path name through some gtkosx_... call, and store it in datadir, overwriting the (Linux) value to which it was initialized. You could then configure engines with directories like -fd ~~/Fairy-Max, or ~~/../Fairy-Max, etc. And you should refrain from any cd in the launch script, so that the current directory is preserved.

[JoshPettus]

Yah, that sounds like it will work just fine!
the function I think we want is:

gtkosx_application_get_bundle_path()

as oppose to the executable path which includes the name of the executable.

[hgm]

OK, I put this in, (both in master and v4.7.x), and pushed the whole thing to Savannah.

Currently all patches are under control of @ifdef OSX, but Arun suggested there might be a standard symbol like __OS_X__ that an OSX compiler might define (just like MSVC would define MSC_VER). If that is the case, it would be easier to change to that.