XBoard for Mac: Zippy problems

[hgm]

The xboard in use is the one distributed by MacPorts which is version 4.7.3. This is only slightly behind version 4.8.0-2 which is distributed by Debian. Both are built for X11. Are these obsolete? If so, then someone should report this to MacPorts and Debian.

Obviously if 4.8.n exists, 4.8.n-1 must be buggy and any 4.7.x must be obsolete. We don't step up the numbers just because we like counting...

The important difference between 4.7 and 4.8 is that in 4.8 we declared the GTK build to be stable and the preferred build. We did report that to Debian, and I though that they do supply the GTK build now as binary package, (and that this in fact is the reason for the '-2' suffix). Don't know about MAcPorts, don't even know what it is...

BTW, there is a slight problem with the Debian xboard package: https://lintian.debian.org/tags/source- ... -file.html

The source tar ball contains sources of both WinBoard and XBoard. I guess the Linux people don't like that, and consider all the stuff only needed for building XBoard as a bug.

The Gtkosx xboard has problems, particularly for Mac users who are trying to connect an engine to an ICS. These problems are unlikely to be resolved until there is sufficient testing by an xboard maintainer and documenter who has a Mac and who is trying to connect an engine to an ICS. In the interim, end users would save much time if the suggested addendum were added to the xboard documentation.

This is a bit weird, as this version should only differ in the use of the front-end, which is used in all modes, not only in ICS mode. If there are any problems, they should be minor, and easy to solve.

If any time is to be spent of XBoard for Mac, I prefer to spend it on fixing those problems, rather than creating documentation for obsolete versions, which is a step backwards, and probably more work...

So far I am only aware of two problems: spurious invocations, and unfavorale choice of accelerator keystrokes that clash with standard editing keystrokes. As to the invocations, the existing logic might indeed be in error, although I don't see yet how this could lead to multiple invocations:

Code: Select all

#ifdef OSXAPP
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;
}

GtkosxApplication *theApp;
#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 OSXAPP
    {   // prepare to catch OX OpenFile signal, which will tell us the clicked file
	char *path = gtkosx_application_get_bundle_path();
#ifdef ENABLE_NLS
	char *res_path = gtkosx_application_get_resource_path();
	snprintf(localeDir, MSG_SIZ, "%s/share/locale", res_path); // redefine locale dir for OSX bundle
#endif
	theApp = g_object_new(GTKOSX_TYPE_APPLICATION, NULL);
	snprintf(masterSettings, MSG_SIZ, "%s/Contents/Resources/etc/xboard.conf", path);
	snprintf(dataDir, MSG_SIZ, "%s/Contents/Resources/share/xboard", path);
	snprintf(svgDir, MSG_SIZ, "%s/themes/default", dataDir);
	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);
	g_signal_connect(theApp, "NSApplicationWillTerminate", G_CALLBACK(ExitEvent), 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

The global flag 'suppress' is used to decide if reception of an OS X 'ApplicationOpenFile' signal', which sends us an argument list, will lead to forking off of a new XBoard instance (with those arguments), or just saves the arguments for use in the current instance. The latter should only happen when XBoard is starting up, and receives its own arguments through the OpenFile signal.

At startup XBoard waits some msec, and then starts checking whether an OpenFile signal has arrived, if it expects one. It only does this when 'suppress' was set, so that when the signal did arrive, the command line accompanying it will have been saved, and can be used to repair its own argv. After that, suppress is reset, so that future OpenFile signals will force forking off a new instance with those arguments.

There are two scenarios that could lead to spurious instances: either OS X sends an OpenFile signal when XBoard did not expect it, because it already was invoked with a non-empty command line. Or it could be that it was invoked without command line, and the command line was sent after it timed out waiting for it. The originally started instance would then remain without arguments, and the arguments intended for it would go to a newly forked-off instance.

We should be able to figure out which is the case by putting in some printf statements to a log file. If the OpenFile signal comes late, we just should wait longer for it during startup. But you cannot wait forever if you are not sure that it is going to come. The problem is that the user could have invoked XBoard without arguments, so that absense of arguments is no sure indication that OS X will send the true command line with an OpenFile signal.

[JoshPettus]

I'm afraid I'm actually having difficulty bundling xboard .app at the moment due to some strangeness with the makefile or more likely my setup... I asked Arun about it in the email list, but he has been busy lately.

The spurious call in question is interesting. Say I open xboard.app with

Code: Select all

open -a xboard.app --args -ics -icshost freechess.org -icshelper ~~/../../bin/timeseal -icsUp true 

I end up with 2 xboards. One that opens xboard in ics mode connected to fics, and one that opens xboard in -ncp mode and fails at opening a file called freechess.org

the spurious instances only happen when launching with the -ics command and seems controlled when specifying -ncp before -ics

Code: Select all

open -a xboard.app --args -ncp -ics -icshost freechess.org -icshelper ~~/../../bin/timeseal -icsUp true

also it doesn't happen when using a macro from the conf file

Code: Select all

open -a xboard.app --args -ics fics

My point is, we are dealing with something very specific.

My gut tells me the problem is the -icshost command. it is relaying both as an argument to -icshost and is telling xboard to open -icshost's argument as file.

Also for the record the gtk on macports doesn't require x11, but it is an option, just don't use the quartz variant. (+quartz)[/code]

[hgm]

The spurious call in question is interesting. Say I open xboard.app with

xboard.app is how you called the XBoard executable, in the App bundle?

Code: Select all

open -a xboard.app --args -ics -icshost freechess.org -icshelper ~~/../../bin/timeseal -icsUp true 

I end up with 2 xboards. One that opens xboard in ics mode connected to fics, and one that opens xboard in -ncp mode and fails at opening a file called freechess.org

This is truly weird. It means something must have generated a command "xboard freechess.org". This could have happened because the original XBoard instance was launched with its original command line (and thus not expecting any signal), and still received an 'OpenFile' signal from OS X not with the original command line, but just with "freechess.org". No idea why OS X would do that.

the spurious instances only happen when launching with the -ics command and seems controlled when specifying -ncp before -ics

Code: Select all

open -a xboard.app --args -ncp -ics -icshost freechess.org -icshelper ~~/../../bin/timeseal -icsUp true

That is also weird. Could it be that OS X just looks at the first 3 arguments, ad sends an OpenFile signal with the first one that doesn't start with '-'? What happens if you put -autoKibitz instead of -ncp? Or move the "-icsUp true" in front? Does it then start an extra instance that tries to open the file 'true'? Or would it reserve that behavior for arguments that end on ".xxx", under the assumption this will be a filename extension? What happens if you try to connect to "freechess" instead of "freechess.org"? (This will not be able to connect in the intended instance, of course, but do you also get an extra instance?)
And what if you try to connect to winboard.nl? Or refer to the -icshost by IP number?

also it doesn't happen when using a macro from the conf file

Code: Select all

open -a xboard.app --args -ics -icshost fics

Any idea why that would be the case?

Well, it fits with the theory that it triggers on the .org part...

Also for the record the gtk on macports doesn't require x11, but it is an option, just don't use the quartz variant. (+quartz)[/code]

I don't quite understand that.

[JoshPettus]

The spurious call in question is interesting. Say I open xboard.app with

xboard.app is how you called the XBoard executable, in the App bundle?

Actually no, because it wouldn't open xboard in a terminal, which would cause the End of File error with the ICS. But it does make for convenient testing, and is certainly viable for any non ics needs.

That is also weird. Could it be that OS X just looks at the first 3 arguments, ad sends an OpenFile signal with the first one that doesn't start with '-'? What happens if you put -autoKibitz instead of -ncp? Or move the "-icsUp true" in front? Does it then start an extra instance that tries to open the file 'true'?

It does! and and it tries to open a third instance for freechess.org, so it doesn't look like it's at least assuming a file of .xxx.... It just opens it

Also for the record the gtk on macports doesn't require x11, but it is an option, just don't use the quartz variant. (+quartz)[/code]

I don't quite understand that.[/quote]

I mean to say that there are both versions available on macports, a quartz version and a x11.

[hgm]

Actually no, because it wouldn't open xboard in a terminal, which would cause the End of File error with the ICS. But it does make for convenient testing, and is certainly viable for any non ics needs.

So what is it? A shell script?

It does! and and it tries to open a third instance for freechess.org, so it doesn't look like it's at least assuming a file of .xxx.... It just opens it

So it issues both an extra 'xboard true' and and 'xboard freechess.org' command? I could understand it if it would send a separate OpenFile command for any argument that does not start with a hyphen. But then I don't understand hof a leading -ncp would prevent it from sending one for freechess.org. And why would this only bother us in -ics mode, and not in any of the other modes?

If OS X could potentially send a whole bunch of OpenFile commands at startup, one for each option value, we should simply have XBoard ignore all OpenFile commands it receives during the first second or so, rather than just the first it receives.

[JoshPettus]

So what is it? A shell script?

just a command in the terminal to open the application

So it issues both an extra 'xboard true' and and 'xboard freechess.org' command? I could understand it if it would send a separate OpenFile command for any argument that does not start with a hyphen. But then I don't understand hof a leading -ncp would prevent it from sending one for freechess.org. And why would this only bother us in -ics mode, and not in any of the other modes?

To be honest I have no idea, why does it not do it with say:
-fcp engine? I admit, it's strange...

If OS X could potentially send a whole bunch of OpenFile commands at startup, one for each option value, we should simply have XBoard ignore all OpenFile commands it receives during the first second or so, rather than just the first it receives.

except what if it would some how block when actually want the open command? What if we were to limit it to just the extensions xboard knows? .fen, .pgn, .trn, and xop?

[hgm]

Well, it seems that XBoard does get the entire command line when it is invoked from a terminal command or with 'open'. The only case where we have a real need for it is when you click a file. The OS X launches XBoard without any arguments, and we have to wait for the OpenFile command to get the name of the clicked file.

So it seems OK to ignore all OpenFile commands for the first second if there already were arguments on the command line, and otherwise only pay attention to the first OpenFile signal. It is unlikely that the user woul start up a new instance of XBoard within one second after the first. If he starts up one later, the OpenFile signal going to the already running instance would fork a new instance off, because the 1 sec by then has expired.

Could it be that the -ics option has some special meaning in OS X, that it only exhibits this weird behavior there?

[JoshPettus]

So it seems OK to ignore all OpenFile commands for the first second if there already were arguments on the command line, and otherwise only pay attention to the first OpenFile signal.

Ah I see, that would work then.

Could it be that the -ics option has some special meaning in OS X, that it only exhibits this weird behavior there?

I don't see how...It would sure be nice for our bugs to have the decency of some sort of actual pattern or predictability...

[hgm]

Can you run any tests at all, at the moment? If the current Makefile is corrupted, could you test on an older version where it still worked?

It would be very helpful to know exactly what is going on, by printing info on what the OpenFile commands exactly give us on some log file. This can be achieved by inserting in critical places

Code: Select all

{FILE *f=fopen("FILENAME", "a"); fprintf(f, MESSAGE); fclose(f);}

where FILENAME is some path name to a writable place, and MESSAGE dependent on the place where we insert it. For instance, at the beginning of StartNewXBoard() we could put MESSAGE =

"%d: start new, suppress = %d, path='%s'\n", getpid(), suppress, path

And in main() we could put before "if(argc == 1)" a printf with MESSAGE =

"%d: new instance, argc=%d argv='%s'\n", getpid(), argc, argv[1]

and after the line "suppress = 0" MESSAGE =

"%d: done waiting, clicked = '%s'\n", getpid(), clickedFile

[JoshPettus]

I bet I can work my way around it, I'll give it a try tonight, I'm afraid I don't have time at the moment.