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 _______________________________________________ Gtk-osx-users-list mailing list Gtk-osx-users-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-osx-users-list
