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

[Olivier Sessink <oliviersessink gmail com>]

On 06/14/2013 10:45 PM, Richard Procter wrote:

> 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. 

it's not about the GUI, it is about thread synchronization. When the
thread is finished it returns the result to the main program using
g_idle_add() so the event loop must be running.

[..]
> > 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. 

so what I understand now, if I connect the signal and start gtk_main()
without calling gtkosx_application_ready() it does not work because
NSApplication::FinshedLaunching is not yet called.

But why does it not work if I connect the signal and start gtk_main()
and *after that* call gtkosx_application_ready()...?

Olivier