GNOME Bugzilla – Bug 677776
filter popup windows get hidden behind main image window
Last modified: 2016-06-07 07:42:35 UTC
On the native OS X 10.7.3 Gimp 2.8.0 build (as found here: http://www.gimpchat.com/viewtopic.php?f=7&t=4440&start=10#p55119), the windows that appear when using a filter get displayed behind the main image window when using single interface mode with a maximized screen. When I first noticed this I was using a dual monitor setup, but it also happens when using just one monitor on my system.
I can confirm this. I use 10.6.8 (Snow Leopard) with one monitor.
*** Bug 683155 has been marked as a duplicate of this bug. ***
I can confirm this.
I can confirm, on Lion 10.7.5, GIMP 2.8.3. Not only filter windows, but also Export Image -> Export image as JPEG/PNG/.. etc. It's very annoying
Created attachment 226517 [details] [review] dialogs no longer pop up in the background
... I've just attached a patch to fix this issue. This patch is a more robust version of the one I've posted a few days ago on the devel list in https://mail.gnome.org/archives/gimp-developer-list/2012-September/msg00020.html It doesn't use the mostly deprecated Carbon framework. It's now based on Cocoa and works well on 10.6, 10.7 and 10.8 AFAICS this fixes #678359 too.
Created attachment 226518 [details] [review] Simone's patch, but using [NSApp activateIgnoringOtherApps] instead of an applescript call.
Thanks Simone and Daniel, that looks really promising. I don't have a Mac around in the next 10 days or so, but something like this will definitely be in 2.8.4. I say "something like" because that looks like it could be done generically in libgimp whenver a plug-in procedure is called interactively, and if the [NSApp activateIgnoringOtherApps] is not enough, we should make sure the newly shown dialog actually becomes key window by fixing GTK/GDK.
*** Bug 686537 has been marked as a duplicate of this bug. ***
*** Bug 678359 has been marked as a duplicate of this bug. ***
*** Bug 686587 has been marked as a duplicate of this bug. ***
Why does the patch set type hint to GDK_WINDOW_TYPE_HINT_UTILITY?
Fixed in master and gimp-2-8, without the window hint. Thanks Simone and Daniel for the patches! commit f3de4b4a24e0e50c7a31829c5ad170e3d3ee5edf Author: Michael Natterer <mitch@gimp.org> Date: Wed Nov 7 23:44:35 2012 +0100 Bug 677776 - filter popup windows get hidden behind main image window On OSX, call [NSApp activateIgnoringOtherApps] when a plug-in dialog is shown, so the plug-in process becomes the active app, and the dialog gets focussed. In order to avoid doing this in GimpDialog (which is also used in the core), do it in gimp_ui_init() which all interactive plug-ins call, and when gimp_temp_proc_run() is called interactively, to catch repeated activation of an already running plug-in. Also, set GimpDialog's initial position to GTK_WIN_POS_CENTER, or they will pop up in the top left corner. Inspired by patches from Simone Karin Lehmann and Daniel Sabo. (cherry picked from commit 0b56aa0d133a9743dca74701a54f21cf9c609f7d) libgimp/Makefile.am | 14 +++++++++++--- libgimp/gimp.c | 15 +++++++++++++-- libgimp/gimpui.c | 8 ++++++++ libgimpwidgets/gimpdialog.c | 4 ++++ 4 files changed, 36 insertions(+), 5 deletions(-)
(In reply to comment #12) > Why does the patch set type hint to GDK_WINDOW_TYPE_HINT_UTILITY? Dialogs will behave more like modal dialogs.
(In reply to comment #13) > Fixed in master and gimp-2-8, without the window hint. Thanks Simone and > Daniel for the patches! > > commit f3de4b4a24e0e50c7a31829c5ad170e3d3ee5edf > Author: Michael Natterer <mitch@gimp.org> > Date: Wed Nov 7 23:44:35 2012 +0100 > > Bug 677776 - filter popup windows get hidden behind main image window > > On OSX, call [NSApp activateIgnoringOtherApps] when a plug-in dialog > is shown, so the plug-in process becomes the active app, and the > dialog gets focussed. > > In order to avoid doing this in GimpDialog (which is also used in > the core), do it in gimp_ui_init() which all interactive plug-ins > call, and when gimp_temp_proc_run() is called interactively, to > catch repeated activation of an already running plug-in. > This works well for normal plug-ins. But for script-fu plug-ins this onky works for the first time you call a script-fu plug.in. Repeatedly calling a script-fu plug-in will give focus to the dialog, but doesn't bring it to front so it still pops up behind the main window.
Ouch, reopening.
Setting the type hint to GDK_WINDOW_TYPE_HINT_UTILITY will be a workaround for the script-fu issue.
Oh well, better than the alternative I'd say.
The centering code just moved to a better place: commit 908a71c4cf28d9d144f8853b32e0da17a6859b10 Author: Michael Natterer <mitch@gimp.org> Date: Sun Nov 11 21:09:46 2012 +0100 Bug 684003 - When using the main window in secondary monitor... If gimp_window_set_transient_for() fails (due to platform restrictions), at least set GTK_WIN_POS_CENTER on the window, so it gets centered on the monitor where the mouse is. This also removes the need for OSX specific centering code in GimpDialog (bug 677776). (cherry picked from commit 9e5ed1e70acfef7a488982ae42ea08c32e18a52d) libgimp/gimpui.c | 39 +++++++++++++++++++++++++++------------ libgimpwidgets/gimpdialog.c | 4 ---- 2 files changed, 27 insertions(+), 16 deletions(-)
Fixed again in master and gimp-2-8: commit d29f273566ddc55075a259e4a95b067067d67371 Author: Michael Natterer <mitch@gimp.org> Date: Sun Nov 11 21:19:17 2012 +0100 Bug 677776 - filter popup windows get hidden behind main image window On OSX, set all transient plug-in windows to UTILITY, so they appear on top of the image window, which is a bad hack. See the comment in gimp_window_set_transient_for_display(). (cherry picked from commit 018fc32727d66a70359d95ee4f13ea98e775d684) libgimp/gimpui.c | 16 ++++++++++++++++ 1 file changed, 16 insertions(+)
(In reply to comment #20) > commit d29f273566ddc55075a259e4a95b067067d67371 > Author: Michael Natterer <mitch@gimp.org> > Date: Sun Nov 11 21:19:17 2012 +0100 > > Bug 677776 - filter popup windows get hidden behind main image window > > On OSX, set all transient plug-in windows to UTILITY, so they appear > on top of the image window, which is a bad hack. See the comment in > gimp_window_set_transient_for_display(). I've found a more elegant solution without the need to use GDK_WINDOW_TYPE_HINT_UTILITY. And I've fixed another bug regarding script-fu plug-ins. Because script-fu itself doesn't exit, it will not switch back to the main image window and so 'script-fu' still appears in the menu bar and the main image window does not get focussed. This is fixed too in my patch. The patch is attached. Nevertheless, it might be worth thinking about keeping GDK_WINDOW_TYPE_HINT_UTILITY anyway, although I now personally prefer not to set it.
Created attachment 228823 [details] [review] script-fu plus-ins open on top and after exiting, the main window gets focus back
Very cool :) Does the [NSApp arrangeInFront: nil] also work if you add it in libgimp/gimp.c:gimp_temp_proc_run()? That would make it work for all plug-ins with interactive temp procedures, not just for script-fu (e.g. also for the help browser).
This hopefully fixes the showing part for good this time, master and 2-8: commit 43cc0949f2104e4a9397c3c1e99e3aa023c655b5 Author: Michael Natterer <mitch@gimp.org> Date: Mon Nov 12 23:42:15 2012 +0100 Bug 677776 - filter popup windows get hidden behind main image window Simone found a better way than setting plug-in windows to UTILITY: simply call the proper API, [NSApp arrangeInFront: nil]. (cherry picked from commit ab801970ca44fbfbbc2902d33f2ac6b70dd0da0f) libgimp/gimp.c | 2 +- libgimp/gimpui.c | 27 +++++++++++++++++---------- 2 files changed, 18 insertions(+), 11 deletions(-)
The hiding part doesn't seem to work reliably though, it makes script-fu permanently hidden sometimes. Does that just always work for you?
yes it will work. I've just done some random calls to regular plugins and scripts, aborting them, repeatedly calling them, running them and so on. Everything worked well.
Strange, it doesn't here. I'm on 10.7.5.
hhm, you've placed [NSApp arrangeInFront: nil] in gimp_window_transient_show () and setupup a signal to call gimp_window_transient_show (). Maybe that makes the difference. I've discovered that needed to call gtk_main_iteration () right after [NSApp hide: nil] to get the hiding processed before gtk_main_quit() gets executed. Dropping the call to gtk_main_iteration () will permantly hide the dialogs, more exactly on repated calls: show the plugin, process the event, find the hide event, and hide it again so that it doesn't show at all. Maybe that's also the case for your version of the patch by placing it in gimp_window_transient_show (). Did you try my version?
BTW, placing [NSApp arrangeInFront: nil] in libgimp/gimp.c:gimp_temp_proc_run() doesn't work.
Yes, but only once, and it always works the first time. I guess if that version always works, we need to experiment a bit until the arrangeInFront works in gimp_window_transient_show(), like connect_after, or processing all pending events...
but if the hiding part doesn't work, did you call gtk_main_iteration () right after [NSApp hide: nil]?
Yes, but apparent with the arrangeInFront in the "show" callback, we need to process all events that are queued, which is safer anyway. Pushed to master and gimp-2-8: commit a766aa9730c619960573d8e58f6cad4726b49494 Author: Michael Natterer <mitch@gimp.org> Date: Tue Nov 13 00:45:45 2012 +0100 Bug 677776 - filter popup windows get hidden behind main image window Apply modified patch from Simone Karin Lehmann which makes sure script-fu gets properly hidden after the dialog is done. (cherry picked from commit 83de53ee4de56c41694b7196345586e8f6578d23) plug-ins/script-fu/Makefile.am | 26 ++++++++++++++++++-------- plug-ins/script-fu/script-fu-interface.c | 16 ++++++++++++++++ 2 files changed, 34 insertions(+), 8 deletions(-)
... what about processing the events right after arrangeInFront too? Wouldn't this solve the issue with permantly hidden dialogs?
That problem seems gone with above commit, and when showing we call gtk_dialog_run() anyway which processes events. If you don't find any ill behavior, I think it's fixed :) Thanks for the patches!
hhmm, I don't want to bother you. AFAICS your commits work fine. So the bug is fixed. But although it would be good to have a working gimp_window_set_transient () on OSX, I think the call to [NSApp arrangeInFront: nil] should not be placed in gimp_window_set_transient. Placing arrangeInFront in gimp_window_set_transient has no effect on regular plug-ins or on other dialogs. It's only necessary for script-fu. And it depends on calling activateIgnoringOtherApps first. Someone reading the code could think that arrangeInFront makes windows transient on OSX which is not true except for script-fu. Further, the code connecting and disconnecting the show signal is only needed to ensure that arrangeInFront gets called after showing the script-fu dialog. Why not placing arrangeInFront into script-fu-interface.c right after a call to gtk_widget_show (dialog) as I did in my patch? IMO this would be much clearer about what arrangeInFront really does and avoids all the hassle with connecting and disconnecting the show signal. And AFAICS there's no need to test for multiple pending events after [NSApp hide: nil]. If there were other events than the one from [NSApp hide: nil], the code would be necessary on other platforms too and not only on OSX. As you can see, my patch works reliably, so why not using this version in a sense of code clarity? BTW, what's the advantage of g_main_context_iteration() over gtk_main_iteration()?
I want to keep platform-specific code out of plug-ins as much as possible. Fixing script-fu fixes only script-fu. The help browser has the same problem, so have arbitrary 3rd party plug-ins which we can't patch, so the code has to live in libgimp. Fortunately the help browser doesn't suffer from the hiding problem. Doing just one main loop iteration didn't hide script-fu for me, and using the GLib construct is just a habit, I guess. Generally, event delivery is not always a deterministic thing, so flushing the queue is the safe thing here, you can't even be sure the first event in the queue is the one you want to process.
*** Bug 689130 has been marked as a duplicate of this bug. ***
*** Bug 697086 has been marked as a duplicate of this bug. ***
Does a bug like this exist for Windows 7? Because I'm experiencing similar symptoms in GIMP 2.8.4 with some of Script-Fu windows. Specifically, when I run any Script-Fu for the first time after starting GIMP, its dialog appears behind the image window (I'm using multi-window mode).
The same bug happens for me again with Parthas 2.8.6 build on OS X 10.6.8. -> thus reopening the bug. See also bug #138298 for the same behaviour on Windows.
Dialogs are now utility windows. Marking as fixed.
The bug is still present in GIMP 2.8.16 x64 on Windows 10, using single interface mode with a maximized screen.
José, this bug was filed for the behavior on OSX. See comment 40.