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

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,

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.

John Ralls

Gtk-osx-users-list mailing list
Gtk-osx-users-list gnome org

Attachment: gedit.c
Description: Binary data

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