OSX Xboard 4.7.2 .app

[hgm]

No I drag the launcher script and the pgn file so essentially it comes down to

Xboard PGNFILE in the terminal. then I hit enter.

Ah, OK. And that apparently generates an OpenFile signal to the XBoard you just started that way. (And in response to that it will start another by calling system("xboard PGNFILE"), which presumably behaves exactly as if you had typed that in a terminal, so that it again receives the OpenFile signal, etc.)

It is a bit weird that XBoard started from the command line would receive an OpenFile signal, and even weirder that it apparently receives the PGNFILE that was its argument with that signal. How could OSX know that PGNFILE was actually a file to be opened? What happens when you type "xboard -ncp" or "xboard -fcp crafty"? Would it then also receive OpenFile requests for the 'files' with name -ncp or -fcp? And what if you start it without arguments altogether? Would you still get an OpenFile signal, but with a NULL name as path?

If there always is an OpenFile event after starting XBoard, we should simply ignore the first such event. This can be done by adding two lines:

Code: Select all

StartNewXBoard()
{
  char buf[MSG_SIZ];
  static int first = TRUE; // ADD
  if(first) { first = FALSE; return TRUE; } // ADD
  snprintf(...
}

The first time it is called StartNewXBoard would then terminate before it did anything.

[JoshPettus]

It doesn't get an open signal when I open with any of those other options. I'll have to try the code in a few hours though.

[hgm]

OK. That surprises me, because it must mean that somehow the terminal must have been smart enough to remember that PGNFILE was a file you dragged there, despite the fact that it only appeared there as a string of characters, looking very similar to those you could have typed yourself without dragging anything. But perhaps Mac terminals are that smart.

Do you really get the same result (i.e. also an OpenFile signal) when you would NOT have dragged the file to the terminal, but typed its name through the keyboard?

If that is the case, OSX must use some heuristic too, to decide if the first argument is a file, that makes it decide -ncp is not a filename, but /Applications/XBoard/... is. That could be as simple as just checking whether it starts with a '/', or it could be as advanced as actually trying to 'stat' a file with that name, to see if it exists.

What happens when you subtly edit the filename to a non-existing one? (E.g. replacing the Crafty-23.5 by Crafty-2.35?)

What happens if the first argument doesn't contain any / at all, because you are tying to open a file in the current directory?

What happens when you create a file called -ncp in the current directory, and start xboard as "xboard -ncp"? Will it then receive an OpenFile signal to open that file?

The problem is that we must be able to predict (from looking at the first argument) whether OS X will send us an OpenFile signal that is merely a duplicate of what we were already requested to do through the command line, and in that case (but that case only) ignore the first OpenFile signal we will receive.

[JoshPettus]

Ok I will list the results

xboard /Applications/Xboard/Josh-Crafty-23.5.pgn = flood!
xboard /Applications/Xboard/Josh-Crafty-2.35.pgn = flood!
xboard something.pgn = flood!
xboard something = flood!
xboard stopflooding! = flood!
xboard -ncp (file in directory) = doesn't flood, opens as the command.
xboard ./-ncp = flood!

If it recognizes it as possibly a file it will try to open that file again and again despite it not being there. the - will be treated as an argument

[JoshPettus]

also
xboard -something = unrecognized argument, but doesn't flood

[hgm]

OK, so the criterion is whether it starts with '-' or not. That is easy enough. Unfortunately this is not known anywhere in xoptions.c, so we will have to touch gtk/xboard.c. Just before main() there, declare an external variable 'suppress', and inside main() itself, add a test to set it when a redundant OpenFile is expected:

Code: Select all

extern int suppress; // ADD

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

    suppress = (argc > 1 && argv[1][0] != '-'); // ADD

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

Then change StartNewXBoard:

Code: Select all

int suppress; // ADD

static gboolean
StartNewXBoard(...)
{
  char buf[MSG_SIZ];
  if(suppress) { suppress = FALSE; return TRUE; } // ADD
  snprintf(...

This assumes you have not implemented the 'first' stuff I posted before. It is nearly the same, except that in stead of 'first' it nor uses 'suppress', which is also known outside the routine, and even in the other file xboard.c, so that it can be set there according to the need to ignore the first OpenFile signal based on inspection of the command-line argument.

[JoshPettus]

There that worked!

Now can we make it so it only opens another instance only if another one is currently active? currently it opens xboard twice and loads in the first one.

Unfortunately the OS is suppressing the second instance till the first one is closed! I should have pointed that out before when it tried to flood. probably the only reason I didn't crash. but I didnt think anything of it till now. so all this may be for nothing....

[hgm]

Are you sure? When you say "xboard xxx.pgn" it should not open it twice now. Because in main() it sees that the first argument does not start with a -, it will ignore the OpenFile signal that normally starts another XBoard. But only the first time; if it gets another OpenFile signal it must be because another PGN file was clicked.

[JoshPettus]

oh no, sorry, if i'm doing xboard xxx in a terminal, that will open up once and in that instance.

I'm talking about opening from the PGN file from the OS open with the finder open-file signal. And there is no xboard instance open. I'm worried about the OS suppression thing too making this all for nothing.

[EDIT]

ah this is the problem

http://reviews.cnet.com/8301-13727_7-57 ... n-in-os-x/

[hgm]

Weird. Can you see what those instances print, or don't they get a terminal window if you start them this way?