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 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():

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. 

Back to GObject school with you! GObject uses two-stage construction, just like Python, and for 
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.

John Ralls

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