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

[John Ralls <jralls ceridwen us>]

On Jun 14, 2013, at 5:59 PM, Richard Procter <richard n procter 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