The current gtk implementation includes some code to execute gtk main loop iterations when closing a dialog, which is necessary for apps which don't otherwise use gtk so that the dialog actually disappears.
However, based on the initial changes proposed in #21 and @meskio's comments, it sounds like this stanza and/or the general approach to spawning dialogs doesn't interact overly well with apps which do use gtk.
Originally this was not a use-case I accounted for, because I figured gtk users already have a cross-platform way to spawn dialogs. But I guess there's an advantage to using the native file browser dialog when running on non-linux platforms so it would be nice to handle better.
(This is kind of similar to #15, where dialogs behave funny on osx if the app doesn't make other cocoa calls.)
The current gtk implementation includes some code to execute gtk main loop iterations when closing a dialog, which is necessary for apps which don't otherwise use gtk so that the dialog actually disappears.
However, based on the initial changes proposed in #21 and @meskio's comments, it sounds like this stanza and/or the general approach to spawning dialogs doesn't interact overly well with apps which do use gtk.
Originally this was not a use-case I accounted for, because I figured gtk users already have a cross-platform way to spawn dialogs. But I guess there's an advantage to using the native file browser dialog when running on non-linux platforms so it would be nice to handle better.
(This is kind of similar to #15, where dialogs behave funny on osx if the app doesn't make other cocoa calls.)