OSX Xboard 4.7.2 .app

[hgm]

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.

[JoshPettus]

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.

[JoshPettus]

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.

[JoshPettus]

And one more thing. To get man and info to work I tried 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
}

menus.c (I know you want to move this passage later anyway)

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
}

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?

[JoshPettus]

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.

[hgm]

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:

Code: Select all

snprintf(buf, MSG_SIZ, "%s %s/Contents/Resources/bin/man.command", appData.sysOpen, DATADIR);

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.

[JoshPettus]

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

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 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?

[JoshPettus]

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.

[hgm]

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

Code: Select all

#ifdef __APPLE__
  { char buf[MSG_SIZ];
    snprintf(buf, MSG_SIZ, "cd %s; open", DATADIR);
    ASSIGN(appData.openCommand, buf);
  }
#endif

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.

[JoshPettus]

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?