Well, as long as you are considering a 4.7.3+:
I just found a bug in 4.7.3 in the PV sorting, and pushed a fix to the v4.7.x branch at hgm.nubati.net. You might as well include that. I am now considering if I should do the same in WinBoard.
OSX Xboard 4.7.2 .app
Moderators: hgm, Rebel, chrisw
-
- Posts: 27793
- Joined: Fri Mar 10, 2006 10:06 am
- Location: Amsterdam
- Full name: H G Muller
-
- Posts: 730
- Joined: Fri Oct 19, 2012 2:23 am
Re: OSX Xboard 4.7.2 .app
Dang...
I just realized if we move xboard.app to somewhere else and launch it, it doesn't update ~/Library/Prefrences/Xboard.conf with the new locations. So they would have to clear the .conf file and start over. I don't even think we want it to automatically force it with the values of the master all the time as that would interfere with whatever the user sets themselves. Although whatever they set themselves will be broken too. is there a way to test if it doesn't find anything to go with whats in the master conf file first before reverting to the compiled defaults?
In regards to the 4.7.x branch, your work with the DataDir should probably be pushed to there too, as it was broken in that branch. Although I'm inclined to go with your various fixes in master.
I just realized if we move xboard.app to somewhere else and launch it, it doesn't update ~/Library/Prefrences/Xboard.conf with the new locations. So they would have to clear the .conf file and start over. I don't even think we want it to automatically force it with the values of the master all the time as that would interfere with whatever the user sets themselves. Although whatever they set themselves will be broken too. is there a way to test if it doesn't find anything to go with whats in the master conf file first before reverting to the compiled defaults?
In regards to the 4.7.x branch, your work with the DataDir should probably be pushed to there too, as it was broken in that branch. Although I'm inclined to go with your various fixes in master.
-
- Posts: 730
- Joined: Fri Oct 19, 2012 2:23 am
Re: OSX Xboard 4.7.2 .app
With master conf settings would have to be default for
polyglot dir
pid
board textures
and sound directory
If it doesn't find these directories/files as valid in the user conf that is.
polyglot dir
pid
board textures
and sound directory
If it doesn't find these directories/files as valid in the user conf that is.
-
- Posts: 730
- Joined: Fri Oct 19, 2012 2:23 am
Re: OSX Xboard 4.7.2 .app
And one more thing. To get man and info to work I tried this
xboard.c
menus.c (I know you want to move this passage later anyway)
Only the os doesn't recognize ~~/ as xboard's bundle directory and I get.
"The file /Users/joshua/~~/Contents/Resources/bin/man.command does not exist."
Anything we can do about this?
xboard.c
Code: Select all
{ // called from menu
#ifdef __APPLE__
char buf[MSG_SIZ];
snprintf(buf, MSG_SIZ, "%s ~~/Contents/Resources/bin/man.command", appData.sysOpen);
system(buf);
#else
system("xterm -e man xboard &");
#endif
}
Code: Select all
InfoProc ()
{
#ifdef __APPLE__
char buf[MSG_SIZ];
snprintf(buf, MSG_SIZ, "%s ~~/Contents/Resources/bin/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
}
"The file /Users/joshua/~~/Contents/Resources/bin/man.command does not exist."
Anything we can do about this?
-
- Posts: 730
- Joined: Fri Oct 19, 2012 2:23 am
Re: OSX Xboard 4.7.2 .app
Sorry to be a pest, but I was wondering if you saw this. These two things are what's stopping me from putting out the next version. I don't want to put out an app where the help suddenly doesn't work, and conf breaking whenever you move the app, interfering with the portability of the app, is hugely problematic. If we can make xboard a little smarter about going to it's default values that would be huge help and also help with people updating the app from 4.7.2, because of the changing the interworkings of the app, it would make it so people would not have to clear their user.conf file.
-
- Posts: 27793
- Joined: Fri Mar 10, 2006 10:06 am
- Location: Amsterdam
- Full name: H G Muller
Re: OSX Xboard 4.7.2 .app
Indeed, the ~~ is now only recognized during option parsing, and in the settings-file name (which is constructed in the OSX initialization code).
Here there already is an sprintf involved, so we can simply print DATADIR with it:
Was the problem with the -lgtkmacintegration already solved? I suppose you already know how it should look in the Makefile that is eventually generated by the autoconf/automake process, as you used to edit that by hand before. Does it come out to look different now that Arun put the OSX stuff in ./configure?
We wanted to do a new development release this weekend. So if you could give a list of patches that you still have to make to get the OS X App, we can still include them. For the remaining stuff I am more or less done. The fatal flaw in the Tournament dialog is now fixed, and as a nice extra we have the collapsable columns in the engine output, implementation of a newly proposed standard for Thinking Output, (extra infos, fail high/fail lows indicators and mate scores). And for WinBoard improved window sticking, which now also works in Win8.
Here there already is an sprintf involved, so we can simply print DATADIR with it:
Code: Select all
snprintf(buf, MSG_SIZ, "%s %s/Contents/Resources/bin/man.command", appData.sysOpen, DATADIR);
We wanted to do a new development release this weekend. So if you could give a list of patches that you still have to make to get the OS X App, we can still include them. For the remaining stuff I am more or less done. The fatal flaw in the Tournament dialog is now fixed, and as a nice extra we have the collapsable columns in the engine output, implementation of a newly proposed standard for Thinking Output, (extra infos, fail high/fail lows indicators and mate scores). And for WinBoard improved window sticking, which now also works in Win8.
-
- Posts: 730
- Joined: Fri Oct 19, 2012 2:23 am
Re: OSX Xboard 4.7.2 .app
Unfortunately the -lgtkmacintegration isn't fixed, and I'm putting it manually in LDFLAGS, as it's not put in automatically there. I'm not sure how to fix it.
---------------------------
The only patch that should be included is the new infoProc and manProc aswell as this stuff I posted before in configure.ac
-------------------------------
You mention the manProc but what should I do for Info? I put in snprint line as a replacement (remembering to change to info.command) and I get this in xboard
I take it DataDir has a different value there?
---------------------------
I've have a, hopefully, simple idea on how to fix the xboard.app configuration problem. That is for xboard to automatically write the value of ~~/ in the user xboard.conf. (call it dataDir) Whenever this value changes it should replace all instances of the old value of ~~/ with the new value. This would ensure that nothing ever breaks. What do you think? Or how about have it actually copy "~~/" to the user .conf from the master as oppose to the generated directory. Whatever is simpler. Second would be ideal as it wouln't require xboard be started twice to fix itself, or can it do the first before it loads all values from the user conf?
---------------------------
The only patch that should be included is the new infoProc and manProc aswell as this stuff I posted before in configure.ac
Code: Select all
dnl| add some libs for OS X
*-apple-* )
AC_MSG_WARN([Apple support is experimental, please report any problems to bug-xboard@gnu.org])
AC_PATH_PROG(SW_VERS, sw_vers)
if test "x$SW_VERS" != "x"; then
AC_MSG_CHECKING(Mac OS X version)
MACOSX_VERSION=`$SW_VERS -productVersion`
AC_MSG_RESULT([$MACOSX_VERSION])
fi
case "$MACOSX_VERSION" in
*)
FRONTEND_LIBS = "$FRONTEND_LIBS -lgtkmacintegration -headerpad_max_install_names"
;;
esac
;;
esac
You mention the manProc but what should I do for Info? I put in snprint line as a replacement (remembering to change to info.command) and I get this in xboard
Code: Select all
The file /usr/local/share/games/xboard/Contents/Resources/bin/info.command does not exist.
---------------------------
I've have a, hopefully, simple idea on how to fix the xboard.app configuration problem. That is for xboard to automatically write the value of ~~/ in the user xboard.conf. (call it dataDir) Whenever this value changes it should replace all instances of the old value of ~~/ with the new value. This would ensure that nothing ever breaks. What do you think? Or how about have it actually copy "~~/" to the user .conf from the master as oppose to the generated directory. Whatever is simpler. Second would be ideal as it wouln't require xboard be started twice to fix itself, or can it do the first before it loads all values from the user conf?
-
- Posts: 730
- Joined: Fri Oct 19, 2012 2:23 am
Re: OSX Xboard 4.7.2 .app
Or how about a mixture of the two and generate the user conf correctly in the first place. Take the value of DataDir and replace any instance in the user conf with ~~/ after saving the file.
-
- Posts: 27793
- Joined: Fri Mar 10, 2006 10:06 am
- Location: Amsterdam
- Full name: H G Muller
Re: OSX Xboard 4.7.2 .app
Indeed, DATADIR was only redefined for OSX inside the xboard.c file. So menu.c would not know about it, and use the value the compiler gets passed as the -DDATADIR flag, supplied by the configure process.
Of course we could resort to extremely dirty kludges. To make an option for ~~ gave me an idea for one:
The -openCommand option could be abused by not setting it to "open", but to "cd BUNDLEPATH; open". I think ';' will be interpreted by the system() function as the start of a new command, so we basically would sneak in an extra cd before the "open" is attempted. We could put in main() some extra lines
This would then automatically prefix any use of the open command with "cd BUNDLEPATH" everywhere. So there would be no need to fix ManProc or MenuProc from what they are now in my repository. And I think the only other places where openCommand is used is by starting a web browser on a URL, which should work from any folder.
These lines would have to be placed after the reading of the regular settings files, (InitAppData()), so that it will overrule the latter when it defined a setting for -openCommand.
Of course we could resort to extremely dirty kludges. To make an option for ~~ gave me an idea for one:
The -openCommand option could be abused by not setting it to "open", but to "cd BUNDLEPATH; open". I think ';' will be interpreted by the system() function as the start of a new command, so we basically would sneak in an extra cd before the "open" is attempted. We could put in main() some extra lines
Code: Select all
#ifdef __APPLE__
{ char buf[MSG_SIZ];
snprintf(buf, MSG_SIZ, "cd %s; open", DATADIR);
ASSIGN(appData.openCommand, buf);
}
#endif
These lines would have to be placed after the reading of the regular settings files, (InitAppData()), so that it will overrule the latter when it defined a setting for -openCommand.
-
- Posts: 730
- Joined: Fri Oct 19, 2012 2:23 am
Re: OSX Xboard 4.7.2 .app
Sounds like a good idea.
Hmm I'm probably not putting it in the right spot. As I'm getting "'AppData' has no member named openCommand." when compiling.
What do you think of my idea of fixing the user conf file after saving?
for use with stuff like Polyglot Dir, Textures, and Sound Dir?
Hmm I'm probably not putting it in the right spot. As I'm getting "'AppData' has no member named openCommand." when compiling.
What do you think of my idea of fixing the user conf file after saving?
for use with stuff like Polyglot Dir, Textures, and Sound Dir?