OSX Xboard 4.7.2 .app

[hgm]

O, my bad. The option is called -openCommand, but inside its value is of course stored as appData.sysOpen.

[JoshPettus]

It compiled but I don't see it behaving the way inwhich you envisioned I put it that bit of code on right after
InitAppData(ConvertToLine(argc, argv));
And it does try to open something but fails, as if the man/info file wasn't there, but the directories leading to it existed. There is no error in the terminal.

My guess is it's checking the default places for the man/info files and they aren't there, (as I didn't do a make install)

Not sure what to do about it.

--------
I found an important fix in your master branch that I forgot about. in gtk/xboard.c

Code: Select all

#ifdef __APPLE__
    {   // prepare to catch OX OpenFile signal, which will tell us the clicked file
	GtkosxApplication *theApp = g_object_new(GTKOSX_TYPE_APPLICATION, NULL);
	char *path = gtkosx_application_get_bundle_path();
	strncpy(dataDir, path, MSG_SIZ);
	snprintf(masterSettings, MSG_SIZ, "%s/../Resources/etc/xboard.conf", path);

snprintf(masterSettings, MSG_SIZ, "%s/../Resources/etc/xboard.conf", path);

needs to be

snprintf(masterSettings, MSG_SIZ, "%s/Contents/Resources/etc/xboard.conf", path);

[JoshPettus]

Ignore my confused conclusions in the previous post.

Once I remembered the "/Contents/" fix, I came to realize I'm not sure it's working where I have it. I am using your master branch unmodified save that one part.

It used the code as was in your master branch and checked.
/Users/joshua/man.command
and Info Proc
doesn't have the apple Def portion so it tried to open xquartz.

[hgm]

I have lost track of where we stand now. Arun and I had planned to do a new development release this weekend, and I am ready with the Linux and WinBoard stuff that I want to go in it. I don't consider it very important whether the OS X fixes go in completely; they should also go into v4.7.x anyway, and we are not releasing 4.7.4 yet, while in the master branch we are still a long way from an official 4.8.0. It seems that for the time being you would be the only one making OS X compiles, so when you are ahead of the official version at Savannah that is not really a problem. So perhaps we should just proceed with the OS X stuff at leasure, and you can release a new App package whenever we are ready, whether it coincides with an official GNU release or not. I pretty much do the same with WinBoard.

I will still fix the path to the master settings file, though.

But when it can find its master settings file, and the ~~ expansion to bundle_path would work in file-option arguments, we should be able to do a lot with that by using ~~ in the master settings file. E.g. when it specified

-fcp ./fairymax
-fd ~~/../Fairy-Max

in the master settings file, this should be enough to let a bare "xboard" command automatically use the Fairy-Max binary that came with the App, which presumably would be looking for its fmax.ini in the current directory, like the Windows version.

But "xboard -fcp fruit" would not work then for a Fruit that came with the App, at least not if Fruit would want to access its own files (say book.bin). It would need an -fd option, like WinBoard needs on Windows, and it would have to be ~~/../fruit, which most people would experience as nerdy. For WinBoard the -fd options also have nasty paths, but there they never have to be typed by the user, but are selected from comboboxes in the Startup Dialog.

I guess people will have to get used to using the -fe / -se options in stead of -fcp / -scp. These would retreive the entire engine line from the engine list, including options like -fd and -fUCI, so that "xboard -fe fruit" would be all that is needed. Perhaps the manual pages of the engines on OSX should have to be adapted that way.

I did try out system("cd xxx; yyy"); , and it indeed executes command yyy in directory xxx. So in principle it should be able to piggy-back a cd command on the "open" command or its OS X replacement. In fact I think I will make it in the upcoming release such that XBoard will replace "%s" in the -openCommand by the DATADIR always. Outside OS X this should not really matter, as the -openCommand would not contain %s, but in OS X DATADIR would be the bundle_path. What exactly we would need to run the required command in a specific directory could then be configured in the master settings file, by including something like

-openCommand "cd %s/../.....; open"

This should already work for ManProc(); InfoProc() would still have to be adapted to not use the "xterm".

I guess in the future we should maintain different master settings files for Linux and OS X in the source tree. (Now there only is an xboard.conf.in, which will be edited in the configure process to make xboard.conf. I guess this editing is no longer needed when we used the ~~ trick XBoard now supports.)

[Sargon]

Thanks to Joshua and hgm for the OSX port! It works great! I saw this thread before but didn't realize it's basically a Winboard port for OSX.

[JoshPettus]

.. So perhaps we should just proceed with the OS X stuff at leasure, and you can release a new App package whenever we are ready, whether it coincides with an official GNU release or not. I pretty much do the same with WinBoard.

That sounds fine! in fact it's actually a bit of a relief. We should consider xboard.app as in alpha state anyway.

~~ in the master settings file. E.g. when it specified

-fcp ./fairymax
-fd ~~/../Fairy-Max

just to clarify it's ~~/Contents/Resources/bin/fairymax
Although I can put it in a Fairy-Max Folder inside the app, but that seems a tad unnecessary. You were right before about it piggying -fd from xboard, so that's fine

in the master settings file, this should be enough to let a bare "xboard" command automatically use the Fairy-Max binary that came with the App, which presumably would be looking for its fmax.ini in the current directory, like the Windows version.

There is probably little point in worrying about command line unless we are setting things up. As far as the user is concerned, OSX doesn't regard Xboard.app as part of path if they are operating in the terminal. we can make it temporarily in a shell with a launching script (export PATH=$PATH:dir sort of thing), but it's not necessary. And the whole point would be for people to have to put their downloaded engines into path as well on their own. Which is "nerdy" and not many would know how or care to do. People will just use the Engine Menu to choose their engines, and use one of my launching scripts for ICS. As it is, fairymax is loaded automatically when they double click on xboard.app.

But "xboard -fcp fruit" would not work then for a Fruit that came with the App, at least not if Fruit would want to access its own files (say book.bin). It would need an -fd option.

This is can be all handled in the master.conf, so most people won't even notice. I don't have any opening book included with fruit. As I expect most to just use one through the GUI /w Polyglot. And therefor can use the in app menus. (either Engine Settings or Common Engine) But if you would like me to include a default fruit book that would be easy to do.

I guess people will have to get used to using the -fe / -se options in stead of -fcp / -scp.

Again I wouldn't worry. It's all being handled through the GUI and people don't even have to use the -fd Browse as it's inferred from the -fcp one if left empty.

-openCommand "cd %s/../.....; open"

This should already work for ManProc(); InfoProc() would still have to be adapted to not use the "xterm".

It probably does and I'm just not doing it right.

I guess in the future we should maintain different master settings files for Linux and OS X in the source tree.

Sounds good, might be a good idea anyway as there are several OS specific things.

[JoshPettus]

Thanks to Joshua and hgm for the OSX port! It works great! I saw this thread before but didn't realize it's basically a Winboard port for OSX.

Thank-you! Technically speaking, as far as Tim Mann was concerned, it's the other way around. Winboard is a port of Xboard. But winboard became as he put it, "the tail that wagged the dog." Really we are trying to mold xboard into being more native with osx.

[JoshPettus]

You were absolutely right! The new open command works great! in the master conf I put

Code: Select all

-openCommand "cd %s/Contents/Resources/bin; open"

In fact here is my current master.conf for the app

https://dl.dropboxusercontent.com/u/504 ... board.conf

Is this ok for the info proc?

Code: Select all

InfoProc ()
{
#ifdef __APPLE__
    char buf[MSG_SIZ];
    snprintf(buf, MSG_SIZ, "%s ./info.command", appData.sysOpen);
    system(buf);
#else
    char buf[MSG_SIZ];
    snprintf(buf, sizeof(buf), "xterm -e info --directory %s --directory . -f %s &",
       INFODIR, INFOFILE);
    system(buf);
#endif
}

I'm sure you are busy but if you could take a look at getting the user .conf to write ~~/ when it's written that way in the master conf, that would be fantastic.

[hgm]

That is not easy, as XBoard immediately expands the ~~ to the full path name on reading. And it also does not keep track of where its eventual option settings came from.

But why would this ever be needed? The user settings file is only created after the App is installed, and at that time the bundle_path is known. So it should always be equivalent to write ~~ or the full path. The ~~ trick is only needed for files we distribute with the App.

[JoshPettus]

App bundles are inherently more portable then a linux install, and it's likely to cause a few annoyances. As I said before, If they move the application, say start it while it still in the DMG, or it's on the desktop and move it to a folder, suddenly everything is broken.. Or if they move the app to an external drive of thumb drive, it's broken, until they clear the user conf file.

Before, I mentioned if xboard knows the value of DATADIR then shouldn't it be easy to automatically replace any instance of that value in the user conf with ~~/ after the creation of the user conf. Say right before it closes?

And if xboard doesn't know then maybe we can save that too in the userconf under the value -dataDir and then have it replace all instances with ~~/ right before exit. Or if you don't want a separate value, derive it from any setting with the directory /Xboard.app + what ever comes before it.