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

On 15/06/2013, at 9:11 AM, Olivier Sessink wrote:

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.

Right. My statement was overly strong: gtk.main_iteration() alllows you to 
single-step the gtk main loop at (programmatically defined) intervals, 
i.e. you needn't be in gtk_main() to process idle callbacks. I don't know 
enough about your program to know whether that's useful to you or not. 

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.

[snip explanation of OpenFile handling] 

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

Yes, I just noticed I was answering a slightly different question to the 
one you asked. 

The gtk-osx integration code defines a GtkApplicationDelegate, which 
processes OpenFile file events for the NSApp and emits the NSApplicationOpenFile

So my guess is that this delegate isn't registered until gtkosx_application_ready() 
is called. However, checking this by the code I get muddled, as this object is only created 
in static void gtkosx_application_init, which is never called in the file in which it is defined
(gtk-mac-integration-2.0.1/src/gtkosxapplication_quartz.c), as far as I can tell. 


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