OSX XBoard/WinBoard.app 4.7.3 Release Thread

[Brandt]

Hi there,

Is there any way to compile xBoard so it would work with voiceover? Currently there are no way, at least that I know of, to either connect to ICC or FICS, or make use of a chess engine in any accessible way.

[Josh Pettus]

If you are using my package I include launch scripts for fics and ics. Drag either in to the same folder as an xboard.app and click on it. To load a chess engine have you tried the built-in load chess engine menus in the program under Engine -> Load First Engine? Works fine for me. I have no idea what you mean about voice overs. Do you mean JAWS? I really don't know much about that.

[H.G.Muller]

There is currently no accessible XBoard version similar to WinBoard for JAWS. A Google SOC project just started that aims to port those patches to XBoard.

[Josh Pettus]

There is currently no accessible XBoard version similar to WinBoard for JAWS. A Google SOC project just started that aims to port those patches to XBoard.

Apparently it is an Apple equivalent to JAWS built right into the OS. (as such there is no JAWS for OSX) and for most coca based apps, it just works. However xboard is a gtk app, and as such there have been many osx integration hurdles for us to overcome. Seeing as there is nothing for this in the OSX gtk mac integration library, I think there is nothing we can do. I read it can be controlled with apple script, perhaps it may be possible to get it to read the moves, but there is no way you have OSX control xboard with just the keyboard. (xboard has its own mechanisms for this for the most part, so it won't be how a voiceover user would expect). Also, I don't see how applescript can get voiceover to navigate/read the menus. (VoiceOver does read the menubar as is though)

[sdchess]

Gah! It has come to my attention that the dmg for the standard xboard app was unopenable.... (hate it when that happens) I uploaded another one.

Where can I download winboard 4.7.3a for mac OS X? These links is not correct today.

[Josh Pettus]

oh dang, sorry, I'll have it back up later today.

[Josh Pettus]

Ok It's back up. Sorry about that. I put it up with a more stable solution. Dropbox is a great tool and all, but it was never meant for mass distribution of files.

Do note it still has the infinite opening bug as before. H.G.M has been on a well deserved hiatus. He will get around to it whenever he does.

Also somewhere along the road, I changed the GTK2 theme to more look like OSX.

[H.G.Muller]

Do note it still has the infinite opening bug as before.

I guess it is high time we should do something about that. I am not sure how it is possible that this problem reverted. This is the relevant code (in gtk/xboard.c) for preventing it (in particular the stuff enclosed in #ifdef __APPLE__ / #endif):

Code: Select all

#ifdef __APPLE__
static char clickedFile[MSG_SIZ];
static int suppress;

static gboolean
StartNewXBoard(GtkosxApplication *app, gchar *path, gpointer user_data)
{ // handler of OSX OpenFile signal, which sends us the filename of clicked file or first argument
  if(suppress) { // we just started XBoard without arguments
    strncpy(clickedFile, path, MSG_SIZ); // remember file name, but otherwise ignore
  } else {       // we are running something presumably useful
    char buf[MSG_SIZ];
    snprintf(buf, MSG_SIZ, "open -n -a \"xboard\" --args \"%s\"", path);
    system(buf); // start new instance on this file
  }
  return TRUE;
}
#endif

int
main (int argc, char **argv)
{
    int i, clockFontPxlSize, coordFontPxlSize, fontPxlSize;
    int boardWidth, w, h; //, boardHeight;
    char *p;
    int forceMono = False;

    srandom(time(0)); // [HGM] book: make random truly random

    setbuf(stdout, NULL);
    setbuf(stderr, NULL);
    debugFP = stderr;

    if(argc > 1 && (!strcmp(argv[1], "-v" ) || !strcmp(argv[1], "--version" ))) {
        printf("%s version %s\n\n  configure options: %s\n", PACKAGE_NAME, PACKAGE_VERSION, CONFIGURE_OPTIONS);
        exit(0);
    }

    if(argc > 1 && !strcmp(argv[1], "--help" )) {
        PrintOptions();
        exit(0);
    }

    /* set up GTK */
    gtk_init (&argc, &argv);
#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/Contents/Resources/etc/xboard.conf", path);
        g_signal_connect(theApp, "NSApplicationOpenFile", G_CALLBACK(StartNewXBoard), NULL);
        // we must call application ready before we can get the signal,
        // and supply a (dummy) menu bar before that, to avoid problems with dual apples in it
        gtkosx_application_set_menu_bar(theApp, GTK_MENU_SHELL(gtk_menu_bar_new()));
        gtkosx_application_ready(theApp);
        suppress = (argc == 1 || argc > 1 && argv[1][00] != '-'); // OSX sends signal even if name was already argv[1]!
        if(argc == 1) {                  // called without args: OSX open-file signal might follow
            static char *fakeArgv[3] = {NULL, clickedFile, NULL};
            usleep(10000);               // wait 10 msec (and hope this is long enough).
            while(gtk_events_pending())
                gtk_main_iteration();    // process all events that came in upto now
            suppress = 0;                // future open-file signals should start new instance
            if(clickedFile[0]) {         // we were sent an open-file signal with filename!
              fakeArgv[0] = argv[0];
              argc = 2; argv = fakeArgv; // fake that we were called as "xboard filename"
            }
        }
    }
#endif


Let me reiterate this stuff, because it was long ago:

The current code was based on the observation that OSX would not start XBoard process to run on a file (by clicking that file, or by using it in a command with a filename as first argument). In stead it would send an "NSApplicationOpenFile" signal to an XBoard process that was already running, and if there were none, it would start and XBoard process without arguments and send the OpenFile signal to that. (The OpenFile signal goes accompanied with tha pathname of the file to work on.)

It can be forced to start a new process with the "open -n ..." command, however. So when an already running XBoard gets this OpenFile signal, it should invoke the "open -n" command to do what OSX should have done in the first place: launch an XBoard on the given file. The problem now, however, is that that new XBoard has to be launched with the command "xboard FILENAME" (achieved by "open -n -a xboard --args xboard FILENAME"), and that OSX then also creates this XBoard process as just "xboard", and sends it the FILENAME immediately afterwards with an OpenFile signal. If that freshly started XBoard now also creates a new XBoard process in response to that OpenFile signal, we get the infinite regression.

So it is essential that OpenFile signals to an XBoard that was just started will not lead to starting a new XBoard, but will be used to supply the FILENAME argument to the current XBoard, which was not doing anything yet. For this reason an XBoard that just starts must wait a bit before starting to do something, to make sure it will not get the OpenFile signal, which might alter what it must do. In particular when that XBoard was started with a command line of just "xboard" (or perhaps "xboard FILENAME"), because those are the situations in which OSX sends the OpenFile signal to a preemptively created fresh XBoard.

The current code attempts this by intercepting the case argc=1 (i.e. command just "xboard"), and then doing an usleep(10000) (=wait 10 msec), before checking if there is a signal (through gtk_main_iteration()), all while suppress=1 (so that the StartNewXBoard() that is invoked by gtk_main_iteration() if there is a signal will not start a new XBoard process, but just remember the filename that comes with the signal as 'clickedFile'). After that it sets suppress=0, however, so any OpenFile signals arriving after that would start new XBoard processes.

My guess now is that waiting 10 msec is not enough. So the OpenFile signal of the newly launched XBoard process would arrive after suppress has already been reset to 0, and thus also create a process with "open -n", which would then receive an OpenFile signal after more than 10 msec, etc. So a first attempt could be to increase that time to 100 msec, or even 1 sec ("usleep(1000000)"). The problem is that we cannot make it wait unconditionally until the OpenFile signal comes, because the user could have started XBoard just with a plain "xboard" command, in which case no OpenFile command would come at all. So there always is the ambiguity between a user doing that (or clicking the xboard icon), and OSX doing that because the user clicked a PGN/FEN/TRN. But perhaps we could make the system more robust by at least weeding out the case where XBoard does it by issuing an "open -n" command. E.g. by calling XBoard under another name in that case.

[Josh Pettus]

Hi! It has been a while.

I tried pasting the code above in above and could still trigger the bug by clicking on a .pgn file twice, or having xboard open and clicking on any associated file type. I then tried changing the "open -n -a \"xboard\" --args \"%s\ to xboard2. As probably expected, it wouldn't open a new xboard if one was already open. Unless I'm miss understanding you. It doesn't make sense. If I enter in the terminal "open -n -a xboard", or open -n -a xboard.app" or "open -n -b org.fsf.xboard.www" (the bundle identifier I set in the info.plist) it opens only once more, as it should.

If you can think of any tests to rule things out let me know.


---
btw I have these bits of code that never made it into your branch and keep having to put in myself.

code to ensure the user xboard.conf remains portable
in args.h:

Code: Select all

    case ArgFilename:
      if(*(char**)ad->argLoc == NULL) break; // just in case
      { char buf[MSG_SIZ];
        snprintf(buf, MSG_SIZ, "%s", *(char**)ad->argLoc);
#ifdef __APPLE__
        if(strstr(buf, DATADIR) == buf)
          snprintf(buf, MSG_SIZ, "~~%s", *(char**)ad->argLoc + strlen(DATADIR));
#endif
        if (strchr(buf, '\"')) {
          fprintf(f, OPTCHAR "%s" SEPCHAR "'%s'\n", ad->argName, buf);
        } else {
          fprintf(f, OPTCHAR "%s" SEPCHAR "\"%s\"\n", ad->argName, buf);
        }
      }
      break;
    case ArgBoardSize:

and infoProc to launch the info.command script
in menu.c

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
}

[Josh Pettus]

Dang, I tried setting it to 200ms via
usleep(200000);
but no luck, same issue

[H.G.Muller]

Strange. In any case I included the above patches. The code I published here was not really different from what we already had. (At least, not that I am aware of. I just printed what we had in xboard.c:main() in the master branch.

I am wondering how to proceed. I am not sure if we can make these extra processes print info somewhere to help us figure out what is going on. They are all started without -debug argument, so I suppose they do not make a debug file. Even if they did, they would probably delete each other's debug file.

We could try to create a common debug file to which they all append. If we would #define a macro to print stuff this way (e.g. just above the code I posted), like

Code: Select all

#define DEBUG(X, Y, Z) {FILE *f=fopen("/home/josh/debug.txt", "a"); fprintf(f, "%d: %s name=%s value=%d\n", getpid(), X, Y, Z); fclose(f); }


(where you might have to adapt the filename in fopen to something that would work on your system), we could write things in the code like

Code: Select all

    DEBUG("file and argc at moment X", clickedFile, argc)


to print the value of a text and integer variable with an identifiable label and the process ID of the responsible process. As a first try we could put such outputs like:

Code: Select all

#ifdef __APPLE__
static char clickedFile[MSG_SIZ];
static int suppress;

static gboolean
StartNewXBoard(GtkosxApplication *app, gchar *path, gpointer user_data)
{ // handler of OSX OpenFile signal, which sends us the filename of clicked file or first argument
DEBUG("OpenFile received with name:", path, suppress)
  if(suppress) { // we just started XBoard without arguments
    strncpy(clickedFile, path, MSG_SIZ); // remember file name, but otherwise ignore
  } else {       // we are running something presumably useful
    char buf[MSG_SIZ];
    snprintf(buf, MSG_SIZ, "open -n -a \"xboard\" --args \"%s\"", path);
    system(buf); // start new instance on this file
  }
  return TRUE;
}
#endif


and

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/Contents/Resources/etc/xboard.conf", path);
        g_signal_connect(theApp, "NSApplicationOpenFile", G_CALLBACK(StartNewXBoard), NULL);
        // we must call application ready before we can get the signal,
        // and supply a (dummy) menu bar before that, to avoid problems with dual apples in it
        gtkosx_application_set_menu_bar(theApp, GTK_MENU_SHELL(gtk_menu_bar_new()));
        gtkosx_application_ready(theApp);
        suppress = (argc == 1 || argc > 1 && argv[1][00] != '-'); // OSX sends signal even if name was already argv[1]!
DEBUG("called with first argument", argv[1]==NULL ? "(none)" : argv[1], argc)
        if(argc == 1) {                  // called without args: OSX open-file signal might follow
            static char *fakeArgv[3] = {NULL, clickedFile, NULL};
            usleep(200000);               // wait 10 msec (and hope this is long enough).
            while(gtk_events_pending())
                gtk_main_iteration();    // process all events that came in upto now
            suppress = 0;                // future open-file signals should start new instance
            if(clickedFile[0]) {         // we were sent an open-file signal with filename!
              fakeArgv[0] = argv[0];
              argc = 2; argv = fakeArgv; // fake that we were called as "xboard filename"
            }
        }
DEBUG("after wait", clickedFile, suppress)
    }
#endif


[Josh Pettus]

Sorry for the late reply, Anyway I plugged in the Debug code plus the #define and got this in the debug.txt

Code: Select all

61338: called with first argument name=(none) value=1
61338: after wait name= value=0
61351: called with first argument name=(none) value=1
61351: OpenFile received with name: name=/Games/Chess/Xboard/herecomethej-Sjeng_11.2.pgn value=1
61351: after wait name=/Games/Chess/Xboard/herecomethej-Sjeng_11.2.pgn value=0
61351: OpenFile received with name: name=/Games/Chess/Xboard/Josh-Crafty-23.5.pgn value=0
61370: OpenFile received with name: name=/Games/Chess/Xboard/Josh-Crafty-23.5.pgn value=0
61370: called with first argument name=/Games/Chess/Xboard/Josh-Crafty-23.5.pgn value=2
61370: after wait name= value=1
61379: OpenFile received with name: name=/Games/Chess/Xboard/Josh-Crafty-23.5.pgn value=0
61379: called with first argument name=/Games/Chess/Xboard/Josh-Crafty-23.5.pgn value=2
61379: after wait name= value=1
61387: OpenFile received with name: name=/Games/Chess/Xboard/Josh-Crafty-23.5.pgn value=0
61387: called with first argument name=/Games/Chess/Xboard/Josh-Crafty-23.5.pgn value=2
61387: after wait name= value=1
...

The first instance I tried opening xboard normally and got a segfault 11 (EDIT: this crash actually happens when the Engine Output window is open in the last comment in your branch! Gtk of course) when, the next one I clicked on the herecomethej-sjeng pgn file and it opened up fine. Then I clicked on the josh-crafty.pgn and it started going through the infinite opens. I hope this helps.


--------------------------
One more thing I would like to see if you have a time, and it's not to difficult, if we could use the gtkosx_application_set_dock_icon_resource () from the integration library to set the dock icon according to who's turn it is. (just like in linux)
I think the command is to set the dock icon from what's in standard linux source, and I have no idea if it will override what's in the info.plist file. But it could be worth a try.

The two icons are Xboard.app/Contents/Resources/XBoard_b.icns and Xboard.app/Contents/Resources/XBoard_w.icns It may only take images, in which I might have to use .pngs of both instead for this command.

[H.G.Muller]

OK, move the line

Code: Select all

suppress = (argc == 1 || argc > 1 && argv[1][00] != '-');

to before

Code: Select all

g_signal_connect(theApp, "NSApplicationOpenFile", G_CALLBACK(StartNewXBoard), NULL);

(It seems we get the OpenFile signal, causing calling of StartNewXBoard, before we even get to the point where it starts waiting for it. Either they signal_connect or the application_ready must do that. I had not expected this would be possible before we start doing the main_iteration stuff. In fact I think that in earlier versions it was not, which is why we added that main_iteration stuff in the first place. It was intended to wait for the OpenFile event, and then execute it. Normally this would only happen when all of main() is done, and you get to the gtk_main_loop at its end.)

[Josh Pettus]

Yay, that did it! Congrats!

Do you want to try the icon switching thing?

[H.G.Muller]

Please remind me; what was "the icon switching thing"?

[Josh Pettus]

Sure, bottom of 4 posts above.

[H.G.Muller]

Ah sorry, I overlooked that completely.

There is a function SetClockIcon in xboard.c that we would have to adapt. It uses icons already stored in memory, though, so we would need another gtkosx call as you mentioned:

Code: Select all

void
SetClockIcon (int color)
{
    GdkPixbuf *pm = *clockIcons[color];
    if (mainwindowIcon != pm) {
        mainwindowIcon = pm;
#ifdef __APPLE__
        gtkosx_application_set_dock_icon_pixbuf(theApp, mainwindowIcon);
#else
        gtk_window_set_icon(GTK_WINDOW(shellWidget), mainwindowIcon);
#endif
    }
}


Unfortunately this requires 'theApp' to be known at this point. I vaguely remember that we used a dirty trick for that in xoptions.c (using g_object_new), but let us do it in a cleaner way here. Just behind the StartNewXboard function, before the #endif add 1 line:

Code: Select all

}

GtkosxApplication *theApp;
#endif


(to define it as a global variable, outside main().) Then change the line that defined it before inside main() to:

Code: Select all

   char *path = gtkosx_application_get_bundle_path();
   theApp = g_object_new(GTKOSX_TYPE_APPLICATION, NULL);


(also moving it one line down), so that it just assigns the value rather than also declaring it at the same time.

Then there is one other issue: at startup the icon is set not through calling SetClockIcon(), but directly. Rather than also putting a gtkosx call there we make it use SetClockIcon() too. (This actually simplifies the code.)

Code: Select all

//    mainwindowIcon = WhiteIcon;
//    gtk_window_set_icon(GTK_WINDOW(shellWidget), mainwindowIcon);
    SetClockIcon(0);


(where I just commented out the old lines.)

[Josh Pettus]

Ok thanks!

a few issues,

What files are defined by the "mainwindowIcon" and where does xboard expect them to be? That would have to be changed. And is there anyway we can use something a little more high res then those default files? I was thinking of:



and

[H.G.Muller]

Code: Select all

    /*
     * Create an icon. (Use two icons, to indicate whther it is white's or black's turn.)
     */
    WhiteIcon  = gdk_pixbuf_new_from_file(SVGDIR "/icon_white.svg", NULL);
    BlackIcon  = gdk_pixbuf_new_from_file(SVGDIR "/icon_black.svg", NULL);


These two lines in main() are used to create the icons. I suppose it can already find them, as they are in the same folder as the pieces, and we can find those. They are also SVG, so the resolution is infinite, in principle. The pixbuf call might rasterize them to nominal size, though. (Seems SVG files do specify a nominal size.) I guess you could use InkScape to edit their sizes.

[Josh Pettus]

Dang, then I must have done something wrong or it's not going to actually work out like we hope, as the dock icon doesn't change.
If it indeed rasterizes the .svg images then it should be ok, and automatically resize it to whatever it needs, i believe. If it doesn't then that could be the issue. I'm pretty sure you can't use an .svg image as an icon in OSX.
the svg icons are in the default folder which is set by the -pieceImageDirectory in the master ini

Just for clarification I got

Code: Select all

void
SetClockIcon (int color)
{
    GdkPixbuf *pm = *clockIcons[color];
    if (mainwindowIcon != pm) {
        mainwindowIcon = pm;
#ifdef __APPLE__
        gtkosx_application_set_dock_icon_pixbuf(theApp, mainwindowIcon);
#else
        gtk_window_set_icon(GTK_WINDOW(shellWidget), mainwindowIcon);
#endif
    }
}

Code: Select all

StartNewXBoard(GtkosxApplication *app, gchar *path, gpointer user_data)
{ // handler of OSX OpenFile signal, which sends us the filename of clicked file or first argument
  if(suppress) { // we just started XBoard without arguments
    strncpy(clickedFile, path, MSG_SIZ); // remember file name, but otherwise ignore
  } else {       // we are running something presumably useful
    char buf[MSG_SIZ];
    snprintf(buf, MSG_SIZ, "open -n -a \"xboard\" --args \"%s\"", path);
    system(buf); // start new instance on this file
  }
  return TRUE;
}

GtkosxApplication *theApp;
#endif

and in main ()

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();
    theApp = g_object_new(GTKOSX_TYPE_APPLICATION, NULL);
   strncpy(dataDir, path, MSG_SIZ);
   snprintf(masterSettings, MSG_SIZ, "%s/Contents/Resources/etc/xboard.conf", path);
   suppress = (argc == 1 || argc > 1 && argv[1][00] != '-'); // OSX sends signal even if name was already argv[1]!
   g_signal_connect(theApp, "NSApplicationOpenFile", G_CALLBACK(StartNewXBoard), NULL);
   // we must call application ready before we can get the signal,
   // and supply a (dummy) menu bar before that, to avoid problems with dual apples in it
   gtkosx_application_set_menu_bar(theApp, GTK_MENU_SHELL(gtk_menu_bar_new()));
   gtkosx_application_ready(theApp);
   if(argc == 1) {                  // called without args: OSX open-file signal might follow
       static char *fakeArgv[3] = {NULL, clickedFile, NULL};
       usleep(10000);               // wait 10 msec (and hope this is long enough).
       while(gtk_events_pending())
      gtk_main_iteration();    // process all events that came in upto now
       suppress = 0;                // future open-file signals should start new instance
       if(clickedFile[0]) {         // we were sent an open-file signal with filename!
         fakeArgv[0] = argv[0];
         argc = 2; argv = fakeArgv; // fake that we were called as "xboard filename"
       }
   }
    }
#endif

and finally

Code: Select all

    /*
     * Create an icon. (Use two icons, to indicate whther it is white's or black's turn.)
     */
    WhiteIcon  = gdk_pixbuf_new_from_file(SVGDIR "/icon_white.svg", NULL);
    BlackIcon  = gdk_pixbuf_new_from_file(SVGDIR "/icon_black.svg", NULL);
//    mainwindowIcon = WhiteIcon;
//    gtk_window_set_icon(GTK_WINDOW(shellWidget), mainwindowIcon);
    SetClockIcon(0);

If we do get this to work, I think id prefer to use the white knight as the white icon as it will look better in the dock.
-----
If this pixbuf stuff doesn't work, can we just have it look for the pre-rastered images in ~~/Contents/Resources folder with the "set doc icon resource" command? Or can it not be used in that way?