On Jun 14, 2013, at 5:59 PM, Richard Procter <richard.n.proc...@gmail.com> wrote:
> > 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(): >>> 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. > > 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. > >> >> [..] >>>> 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. >>> >>> [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 > signal. > > 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. > Back to GObject school with you! GObject uses two-stage construction, just like Python, and for GtkosxApplication, gtkosx_application_init() is the second-stage constructor. It's called automatically by the object system after the user program calls g_object_new() on GtkosxApplication. My understanding of the startup sequence when a user double-clicks a file is: app calls [NSApplication finishLaunching] (wrapped with gtkosx_application_ready()) Launchservices sends in order: 1. applicationWillFinishLaunching: 2. application:OpenFile: 3. applicationDidFinishLaunching: The delegate as currently written ignores the first and last, but perhaps you could stick a printf in the GtkApplicationDelegate's application:OpenFile: method and another just before you connect to the signal to see if there's a timing problem or if GtkApplicationDelegate application:OpenFile: is even getting called. Regards, John Ralls _______________________________________________ Gtk-osx-users-list mailing list Gtk-osx-users-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-osx-users-list
