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

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():

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()...?


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]