From: John Ralls <jralls ceridwen us>
To: Olivier Sessink <oliviersessink gmail com>
Cc: gtk-osx-users-list gnome org; Richard Procter <richard n procter 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 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
_______________________________________________
Gtk-osx-users-list mailing list
Gtk-osx-users-list gnome org
https://mail.gnome.org/mailman/listinfo/gtk-osx-users-list
Attachment:
gedit.c
Description: Binary data