You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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 text was updated successfully, but these errors were encountered:
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 text was updated successfully, but these errors were encountered: