OSX Xboard 4.7.2 .app

[hgm]

So it seems the first time you click the PGN (without any XBoard instances open) indeed XBoard is started up without any arguments. And the routine StartNewXBoard() that processes the OpenFile signal that must follow is never called.

On later clicks everything works as expected. The instance that was first running (process ID 82572) receives the OpenFile signal while it is not scheduled for suppression (suppress = 0). So it forces starting a new XBoard instance (PID 82583) with the use of "open -n". This new instance is apparently called with the filename on its command line. (Did you use --arg with "open -n" to achieve that?) So far so good.

But then something unexpected happens: it also receives an OpenFile signal. I would have expected it to either receive the filename as an argument (when --args was used) or as a signal (without --args).

But then it starts to get absolutely weird: when this unexpected signal (in the just started XBoard) is processed by StartNewXBoard(), suppress is apparently set, so that no new XBoard instance is launched. Which accidentally saves the day, as really no new instance was needed, and we would likely have flooding if it had started one. But the weird thing is that 'suppress' should not have been set! The only place in the code that sets suppress = 1 is inside the if(argc == 1), and argc was obviously 2 (it was just printed).

So there are three mysteries here:
1) Why don't we receive the OpenFile signal in the first XBoard instance that starts? Could it be that the g_signal_connect() for this signal only becomes effective after calling gtkosx_application_ready()? If we did not wait long enough with the usleep() I would at least have expected the signal to be received later, when suppress was already reset to 0. But it is not received (or at least not caught) at all. While earlier, when the g_signal_connect was in the BarEnd case in xoptions.c, the signal was received (initially leading to infinite instances). So even if the signal is only caught after application_ready, it still should be eventually caught (albeit too late), because we do eventually get to BarEnd. It is like the earlier calling of gtk_main_iteration() has somehow flushed the signal. (I added that, because I supposed it would be needed to receive the signal.)

2) Why do we both get a signal transmitting the filename as well as the filename passed as an argument? If it consistently does this, we should again defend against it when XBoard was called with arguments (e.g. when the first argument doesn't start with -).

3) How can it be that suppress was 1 when XBoard was started with an argument. This points to a problem in our own code. (Some leftover assignement to suppress somewhere?)

[hgm]

One more suggestion: perhaps we should do a gtkosx_application_ready(theApp); directly after the g_signal_connect() in main(). Apparently the XBoard instances that were started up when the first was already running did catch the signal (but then ignored it because suppress was 1), and one of the differences is that they got to do gtk_main_iteration() only at the end of main, after gtkosx_application_ready() had been called near BarEnd. (Because argc was not 1 there, so they skipped the gtk_main_iteration we added at the top of main(), while the first instance executed those, possibly flushing the signal.)

We probably should not do the gtkosx_application_ready() twice, so the one near BarEnd in xoptions.c could be changed into

gtkosx_application_sync_menubar(theApp);

[JoshPettus]

Oh yes I did use the --args, as without it nothing ever loaded.

The only line of supress I know of what we changed recently and should be in there is the one we put in main (). Unless I left one in somewhere else by accident while we were switching stuff around. Perhaps I should start from a clean slate, put in the last patch, (which has all the menu stuff and accelerator) And then put in the two sections of code that was for gtk/xboard.c. and the supressline in main. But first I'll give your suggestion a try

[JoshPettus]

Awesome! we almost got it!

The loading files now works perfectly! Loads up one time on initial launch and clicking on a png again loads up another instance! Excellent!

The problem is with the menu now, is the menu sync function the only option? For some inexplicable reason it has added an extra empty apple menu before the Xboard menu, (though it is smaller then the real one). I wouldn't have thought an application would ever need anything to do with the apple menu as that is a system menu. So why would it create one? But there it is!

[hgm]

This is indeed a bit weird. (No matter how wrong we use everything, why would it ever do a thing like THAT???) The description at http://gtk-osx.sourceforge.net/gtk-mac- ... ation.html says "If you add other windows later, you must do everything above for each one's menubar". And the application_ready is described above it. So perhaps we should simply do it a second time near BarEnd. The sync_menubar might not be necessary. So just change that back to gtkosx_application_ready(theApp), and try if that works better.

[JoshPettus]

Crud, same thing. Apparently it's the moving of ready that's causing it. What can we do about that?

Oh no wait I did something wrong when I copied it moved the } up lets see if thats it
[EDIT]
Yah dang, it doesn't matter if I have app ready, sync menu, or just leave both out. same result.
-----
I was looking at the GIMP code a while ago when we were messing with the signal connect. They had a similar problem where they couldn't have ready near it so they had some kind o hack with their event handler.

Code: Select all

 g_signal_connect (osx_app, "NSApplicationOpenFile",
                    G_CALLBACK (gui_unique_quartz_nsopen_file_callback),
                    gimp);

  /* Using the event handler is a hack, it is neccesary becuase
   * gtkosx_application will drop the file open events if any
   * event processing is done before gtkosx_application_ready is
   * called, which we unfortuantly can't avoid doing right now.
   */

......
static gboolean
gui_unique_quartz_nsopen_file_callback (GtkosxApplication *osx_app,
                                        gchar             *path,
                                        gpointer           user_data)
{
  gchar    *callback_path;
  GSource  *source;
  GClosure *closure;

  callback_path = g_strdup (path);

  closure = g_cclosure_new (G_CALLBACK (gui_unique_quartz_idle_open),
                            (gpointer) callback_path,
                            (GClosureNotify) g_free);

  g_object_watch_closure (G_OBJECT (unique_gimp), closure);

  source = g_idle_source_new ();

  g_source_set_priority (source, G_PRIORITY_LOW);
  g_source_set_closure (source, closure);
  g_source_attach (source, NULL);
  g_source_unref (source);

  return TRUE;
}

could that be useful to us?

[Sven]

Crud, same thing. Apparently it's the moving of ready that's causing it. What can we do about that?

Oh no wait I did something wrong when I copied it moved the } up lets see if thats it
[EDIT]
Yah dang, it doesn't matter if I have app ready, sync menu, or just leave both out. same result.

It seems someone else has already had the same problem with two apple menus: https://mail.gnome.org/archives/gtk-osx ... 00008.html

[hgm]

It seems that the first gtkosx_application_ready() creates an empty menu bar (with only the big apple on it), and that when we start creating a menu bar later, and register that with OS X, it puts the entire bar as a sub-menubar within that bar.

This seems a bug in GTK-OSX to me. Unless the idea is that menu bars are hierarchical, and that menu bars belonging to other windows must be sub-menubars of the 'main menubar', when those windows get focus.

[JoshPettus]

Thanks Sven. Looks like they haven't found a way around it, at least as of that post. So that route may be closed to us.

[hgm]

Hmm. Same problem, but no solution...

Perhaps it helps if we create a dummy menu bar before calling the first application_ready (in main()) ?

Code: Select all

gtkosx_application_set_menu_bar(theApp, GTK_MENU_SHELL(gtk_menu_bar_new()));