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

On Jun 13, 2013, at 4:36 PM, Olivier Sessink <oliviersessink gmail com> wrote:

Hi all,

we're currently working to fix some issues with Bluefish on OSX.
Bluefish initializes the GUI in an idle callback. So gtk_main() is
called very early (before there is a window created).

How can you start the event loop in an idle callback? 

I have a question when to call gtkosx_application_ready().

If I call it when the first window is ready, everything works fine
except for one issue: if the application is started from the finder
(using 'open with'), the "NSApplicationOpenFile" signal is not called
for that filename. Once the application is running, the
"NSApplicationOpenFile" signal works fine.

However, if I call it before gtk_main() as stated in the documentation,
I get two 'apple' icons in the top menu bar on the left, and the
NSApplicationOpenFile" signal is working as expected.

How should I handle this?

The issue here is the menubar: For Cocoa applications, the menubar
is a property of the application, while for Gtk applications it's a property
of each window.If you try to call gtkosx_application_ready() before having
a window ready with in particular the System menu (aka the Apple menu)
in place, OSX will make one for you and when you add the first window 
you'll have two.

gtk_main() initializes a few things and then starts the mainloop to accept
events. There's no way to handle signals until it has started, so we have a 
bit of a chicken-and-egg situation because as soon as gtkosx_application_ready()
is called, NSApplicationDelegate processes the FileOpen AppleEvent and 
emits the signal, but the mainloop isn't yet running so there's nothing to handle
the signal and it falls on the floor. I haven't figured out a good way to 
resolve this.

John Ralls

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