Apparently guys doing gedit also had similar problem. They found kind of clever solution, which I do not understand completely, however, it might give some clues for You. See in attached file comment around line 289. Best regards, Andrius
>________________________________ > From: John Ralls <jra...@ceridwen.us> >To: Olivier Sessink <oliviersess...@gmail.com> >Cc: gtk-osx-users-list@gnome.org; Richard Procter ><richard.n.proc...@gmail.com> >Sent: Saturday, June 15, 2013 3:53 AM >Subject: Re: [gtk-osx-users] when to call gtkosx_application_ready() in an >application that initializes in an idle callback > > > >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 > > >
gedit.c
Description: Binary data
_______________________________________________ Gtk-osx-users-list mailing list Gtk-osx-users-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-osx-users-list
