Re: [gtk-osx-users] when to call gtkosx_application_ready() in an application that initializes in an idle callback

[Richard Procter <richard n procter gmail com>]

Hi Olivier, 

On 15/06/2013, at 7:51 AM, Olivier Sessink wrote:

> various other initialization parts of Bluefish use multiple threads, and
> use the main loop to sync the results. If we don't run the first
> initialization inside gtk_main all the threads have to wait for the gui
> to be finished before they can sync their results with the rest of the
> program.

It seems like a lot of hoop-jumping, perhaps there's a way to avoid it?
Have you considered polling the event queue during startup, e.g. 

 while gtk.events_pending():
        gtk.main_iteration()

This avoids starting the main gtk event loop while still allowing the GUI 
to work at (programmatically defined) intervals. 
 
> [...] 
>
> > gtk_main() initializes a few things and then starts the mainloop to accept
> > events. There's no way to handle signals until it has started, so we have a 
> > bit of a chicken-and-egg situation because as soon as gtkosx_application_ready()
> > is called, NSApplicationDelegate processes the FileOpen AppleEvent and 
> > emits the signal, but the mainloop isn't yet running so there's nothing to handle
> > the signal and it falls on the floor. I haven't figured out a good way to 
> > resolve this.
>
> From this description I understand why I get the two apple icons if I
> call gtkosx_application_ready() before the first window is created. But
> I don't understand the other situation: why I cannot catch the
> NSApplicationOpenFile signal if I call gtkosx_application_ready() when
> gtk_main is already running.

Looking at the appropriate docs[1], when the user indicates they want
to open a document in the Finder, OS X injects the appropriate
high-level Apple Event into the application's event queue. As far as
I can tell, all events, whether Apple Events or low-level input
device events, are received asynchronously by the NSApplication via
a Mach port and placed on a single FIFO to be processed by the
application's event loop.

These are then consumed by the GTK event loop, at which point the 
OpenFile event will be discarded if an NSApplicationOpenFile handler 
is undefined. 

If you are interested in the gory details, see [2].

best, 
Richard. 

[1] Apple Events Programming Guide:
http://developer.apple.com/legacy/mac/library/documentation/AppleScript/Conceptual/AppleEvents/AppleEvents.pdf

How an Event Eneters a Cocoa 
Application:http://developer.apple.com/mac/library/documentation/Cocoa/Conceptual/EventOverview/EventArchitecture/EventArchitecture.html#//apple_ref/doc/uid/10000060i-CH3-SW1

[2] gtk+-x.x.x/gdk/quartz/gdkevents-quartz.c:_gdk_events_queue.c 
and gtk-mac-integration-2.0.1/src/GtkApplicationDelegate.c are good places to start, 
also see my post here of Aug 2010 titled 'Notes on handling Apple events with gtk_osxapplication and PyGTK'.