OSX Xboard 4.7.2 .app

[JoshPettus]

Sure, the code is available among many other servers over here
http://artfiles.org/gimp.org/gimp/v2.8/
.10 is the current one.

The code in question with NSApplicationOpenFile starts in gui-unique.c

[hgm]

OK, found it. On my Ubuntu I had the source code of 2.8.8, which did not contain this.

The kludge is rather elaborate, and it definitely is regular C code, so I am not sure if we can use it. (And in any case, I don't understand a syllable of it...) It seems to involve:

Code: Select all

@interface GimpAppleEventHandler : NSObject {}
- (void) handleEvent:(NSAppleEventDescriptor *) inEvent
        andReplyWith:(NSAppleEventDescriptor *) replyEvent;
@end

static GimpAppleEventHandler  *event_handler = NULL;

@implementation GimpAppleEventHandler
- (void) handleEvent: (NSAppleEventDescriptor *) inEvent
        andReplyWith: (NSAppleEventDescriptor *) replyEvent
{
  const gchar       *path;
  NSURL             *url;
  NSAutoreleasePool *urlpool;
  NSInteger          count;
  NSInteger          i;

  urlpool = [[NSAutoreleasePool alloc] init];

  count = [inEvent numberOfItems];

  for &#40;i = 1; i <= count; i++)
    &#123;
      gchar    *callback_path;
      GSource  *source;
      GClosure *closure;

      url = &#91;NSURL URLWithString&#58; &#91;&#91;inEvent descriptorAtIndex&#58; i&#93; stringValue&#93;&#93;;
      path = &#91;&#91;url path&#93; UTF8String&#93;;

      callback_path = g_strdup &#40;path&#41;;
      closure = g_cclosure_new &#40;G_CALLBACK &#40;gui_unique_quartz_idle_open&#41;, // &#91;HGM&#93; This should probably become StartNewXBoard
                                &#40;gpointer&#41; callback_path,
                                &#40;GClosureNotify&#41; g_free&#41;;

      g_object_watch_closure &#40;G_OBJECT &#40;unique_gimp&#41;, closure&#41;;

      source = g_idle_source_new ();
      g_source_set_priority &#40;source, G_PRIORITY_LOW&#41;;
      g_source_set_closure &#40;source, closure&#41;;
      g_source_attach &#40;source, NULL&#41;;
      g_source_unref &#40;source&#41;;
    &#125;

  &#91;urlpool drain&#93;;
&#125;
@end

static void
quartz_init &#40;Gimp *gimp&#41;
&#123;
  GtkosxApplication *osx_app = gtkosx_application_get ();

  g_signal_connect &#40;osx_app, "NSApplicationOpenFile",
                    G_CALLBACK &#40;gui_unique_quartz_nsopen_file_callback&#41;, // &#91;HGM&#93; This must become StartNewXBoard
                    gimp&#41;;

  /* 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.
   */
  event_handler = &#91;&#91;GimpAppleEventHandler alloc&#93; init&#93;;

  &#91;&#91;NSAppleEventManager sharedAppleEventManager&#93;
      setEventHandler&#58; event_handler
          andSelector&#58; @selector &#40;handleEvent&#58; andReplyWith&#58;)
        forEventClass&#58; kCoreEventClass
           andEventID&#58; kAEOpenDocuments&#93;;
&#125;

static void
quartz_exit &#40;void&#41;
&#123;
  &#91;&#91;NSAppleEventManager sharedAppleEventManager&#93;
      removeEventHandlerForEventClass&#58; kCoreEventClass
                           andEventID&#58; kAEOpenDocuments&#93;;

  &#91;event_handler release&#93;;
&#125;

It seems to dig directly into Quarz, in order to convince it to do what it would normally not do before calling gtkosx_application_ready: catch the OpenFile event and pass the accompanying path to StartNewXBoard(). Normally Quarz would send this signal to the GTK-OSX system, which would then happily ignore it, because it knows aplication_ready was not yet called. So the code somehow convinces Quarz to directly invoke the GimpAppleEventHandler code, before passing the signal to GTK-OSX, which then again calls the routine to which we wanted to connect the OpenFile signal.

So their solution is bypassing GTK-OSX, which is pretty complex.

quarz_init contains code that must be executed directly after gtkosx_application_new() in main(). But there apparently is also some code that must be executed just before the process terminates. (but this can be called from XBoard's ShutDownFrontEnd().

Not sure if this would be the best solution.

[Sven]

The kludge is rather elaborate, and it definitely is regular C code, so I am not sure if we can use it. (And in any case, I don't understand a syllable of it...) It seems to involve:

Code: Select all

@interface GimpAppleEventHandler : NSObject {}
- (void) handleEvent:(NSAppleEventDescriptor *) inEvent
        andReplyWith:(NSAppleEventDescriptor *) replyEvent;
@end

static GimpAppleEventHandler  *event_handler = NULL;

@implementation GimpAppleEventHandler
- (void) handleEvent: (NSAppleEventDescriptor *) inEvent
        andReplyWith: (NSAppleEventDescriptor *) replyEvent
{
  const gchar       *path;
  NSURL             *url;
  NSAutoreleasePool *urlpool;
  NSInteger          count;
  NSInteger          i;

  urlpool = [[NSAutoreleasePool alloc] init];

.....

It is Objective-C, therefore no "regular C code". New keywords like "interface" or "implementation" start with a @.

[hgm]

Well, I don't know if this can be compiled with the XBoard Makefile.

[JoshPettus]

Wow...what a mess... There is no need for a rush on the solution mind you, If you want to tackle this sometime next year. I'd understand.

[hgm]

Well, I still would want to give it a try to solve this without all this Objective C stuff. In principle it should be possible to create a menu bar before having processed all options; after all, the menu bar does not depend on the options very much (only the -recentEgines in the engine menu). The logical problem we are facing is that the menu-bar now is created with the main window, the main-window parameters depend on the options, that the options might come from a clicked .xop file, and that we can get the name of the clicked file only after gtkosx_application_ready(), and that we can do the latter only after the menu bar has been created. This vicious cycle could be broken by first creating a menu bar, then issuing gtkosx_aplication_ready(), then receiving the filename, then processing the options in it (in case it was a .xop file), and then popping up a main window without menu bar.

To get the recently-used engines right, we could actually first process options from the standard settings file and the redirections it specifies, then do the menu bar and receive the signal to obtain the command line, and then process the command line (possibly changing option settings through the .xop file), and then bring up the main window in accordings with the now final option settings. The processing of options is already separated like that, in InitAppData() (args.h):

Code: Select all

  /* Parse default settings file if any */
  ParseSettingsFile(settingsFileName, &settingsFileName);

  RECEIVE_FILENAME_AND_RECONTRUCT_COMMAND_LINE_HERE

  /* Parse command line */
  ParseArgs(StringGet, &lpCmdLine);

This would mean, however the -recentEngines appearing in the menu would always be taken from the settings file, and could not be overruled by any -ini files specified through the command line. That doesn't sound very serious, but in fact it is, if, say, an xq.xop file that would be used to configure for Xiangqi would redirect loading and saving of settings to a Xiangqi-specific persistence file (to not mix them with Chess settings). The used Xiangqi engines would then be saved there, but in the next run the engines in the menu would come from the standard settings file used for Chess, and would thus be Chess engines.

Of course we could try to add the -recentEngines to the Engine menu later. If OS X allows that. In this respect I am still a bit puzzled as to how much of the menu bar we must necessarily do before gtkosx_application_ready(). We already tried creating a completely empty menu bar, logging that with OS X, and putting the menu buttons and corresponding menus in it later. This seemed to give the same error message as when we tried to replace the empty menu bar by a new one. (Which is a bit suspect. Are you sure, Josh, that the application_set_menu_bar near BarEnd was commented out when you got that message?) If we are not allowed to put menu buttons in a menu bar already registered to OS X, we could try putting in all menu buttons, but creating the actual menus and connecting those to the buttons later (during GenericPopUp() of the main window). If none of this is allowed, I guess there is little we can do, and we should just live with the double Apple menu on a 'click start'. This is, after all, a GTK-OSX bug, and it is very questionable how far we should go in XBoard to work around it.

[JoshPettus]

I double checked, it is:

Code: Select all

	    {
      		GtkosxApplication *theApp = g_object_new(GTKOSX_TYPE_APPLICATION, NULL);
      		extern MenuItem helpMenu[]; 
      		gtk_widget_hide (menuBar);
      		//gtkosx_application_set_menu_bar(theApp, GTK_MENU_SHELL(menuBar));
      		gtkosx_application_insert_app_menu_item(theApp, GTK_MENU_ITEM(helpMenu[8].handle), 0);
            gtkosx_application_ready(theApp);
  	   } 

I guess we can just live with it, although it's not only when opening files, it's all the time on every start and sticks out like a sore thumb. We could make a but post on their forums

-----------

Oh wow I appear to have found the source repo for the macintegrationlibrary, and macports appear to be quite out of date!

https://github.com/jralls/gtk-mac-integration
whether or not this will fix our issue, idk but it is certainly worth a try. trick would be getting it setup on my system. I guess the best way would be to bug the port maintainer.

[JoshPettus]

macport version currently is 2.0.1

[JoshPettus]

oh well looking at this I'm not sure if our problem is there.

https://github.com/jralls/gtk-mac-integ ... /ChangeLog

Probably should just send him a bug report, see if he can do anything about it.

[hgm]

I double checked, it is:
...

OK, then the error message probably is triggered by adding new menu buttons to a bar after application_ready. But we can still hope adding menus to the buttons, or items to those menus is allowed. If it was, the problem can still be solved by creating the menu buttons earlier.