OSX Xboard 4.7.2 .app
Moderators: hgm, Rebel, chrisw
-
- Posts: 27808
- Joined: Fri Mar 10, 2006 10:06 am
- Location: Amsterdam
- Full name: H G Muller
Re: OSX Xboard 4.7.2 .app
O, my bad. The option is called -openCommand, but inside its value is of course stored as appData.sysOpen.
-
- Posts: 730
- Joined: Fri Oct 19, 2012 2:23 am
Re: OSX Xboard 4.7.2 .app
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
snprintf(masterSettings, MSG_SIZ, "%s/../Resources/etc/xboard.conf", path);
needs to be
snprintf(masterSettings, MSG_SIZ, "%s/Contents/Resources/etc/xboard.conf", path);
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);
needs to be
snprintf(masterSettings, MSG_SIZ, "%s/Contents/Resources/etc/xboard.conf", path);
-
- Posts: 730
- Joined: Fri Oct 19, 2012 2:23 am
Re: OSX Xboard 4.7.2 .app
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.
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.
-
- Posts: 27808
- Joined: Fri Mar 10, 2006 10:06 am
- Location: Amsterdam
- Full name: H G Muller
Re: OSX Xboard 4.7.2 .app
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.)
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.)
-
- Posts: 4
- Joined: Wed Nov 27, 2013 12:18 am
Re: OSX Xboard 4.7.2 .app
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.
-
- Posts: 730
- Joined: Fri Oct 19, 2012 2:23 am
Re: OSX Xboard 4.7.2 .app
That sounds fine! in fact it's actually a bit of a relief. We should consider xboard.app as in alpha state anyway.hgm wrote:.. 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.
just to clarify it's ~~/Contents/Resources/bin/fairymaxhgm wrote: ~~ in the master settings file. E.g. when it specified
-fcp ./fairymax
-fd ~~/../Fairy-Max
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
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.hgm wrote: 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.
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.hgm wrote: 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.
hgm wrote: 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.
It probably does and I'm just not doing it right.hgm wrote: -openCommand "cd %s/../.....; open"
This should already work for ManProc(); InfoProc() would still have to be adapted to not use the "xterm".
hgm wrote: 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.
-
- Posts: 730
- Joined: Fri Oct 19, 2012 2:23 am
Re: OSX Xboard 4.7.2 .app
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.Sargon wrote: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.
-
- Posts: 730
- Joined: Fri Oct 19, 2012 2:23 am
Re: OSX Xboard 4.7.2 .app
You were absolutely right! The new open command works great! in the master conf I put
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?
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.
Code: Select all
-openCommand "cd %s/Contents/Resources/bin; open"
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
}
-
- Posts: 27808
- Joined: Fri Mar 10, 2006 10:06 am
- Location: Amsterdam
- Full name: H G Muller
Re: OSX Xboard 4.7.2 .app
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.
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.
-
- Posts: 730
- Joined: Fri Oct 19, 2012 2:23 am
Re: OSX Xboard 4.7.2 .app
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.
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.