GNOME Bugzilla – Bug 780979
Fullscreen windows with WS_EX_NOACTIVATE | WS_EX_TRANSPARENT interfere with GIMP UI events
Last modified: 2018-05-24 17:42:37 UTC
Thanks to user Floatharr on #gimp, we figured out another application that interferes with certain features of the GIMP user interface on the Windows platform: Strokes Plus http://www.strokesplus.com/ The software optionally uses an invisible window covering the whole screen to paint the gestures users make, and this interferes with the events GIMP (or GTK+) receives, it seems. We suspected similar behavior of the other applications doing this.
For all these stuff, we'd really need a Windows developer willing to spend some time testing. Without one, I fear this is one of these bugs which will stay here forever. :-/ Personally I'd need to be really really bored (or paid) to test. Anyway let's make a "Future" milestone for now.
Turns out that the Strokes Plus community even knows about this issue: http://www.strokesplus.com/forum/topic/750/open-enable-s-if-this-application-is-stopped
And it affects other GTK+ applications, as well, Floatharr has tested this for Inkscape. There's a hint in one of the comments there: "Try unchecking Keep Gesture Window On Top* and Don't Hide Gesture Draw Window*. The gesture drawing surface is a full-screen transparent window. It's possible that Gimp thinks it's an application window and doesn't behave properly." Pure guess: GTK+ is discarding mouse-over events, or not requesting to be notified of them (the symptom was menus sticking around unless the user clicks) if it considers windows covered by other applications' windows. Full-screen transparent windows seem to be a special case that is not handled properly for the MS Windows backend, at least.
That seems like a good use case to maybe even fix all the bugs about applications which make interferences with GIMP. Do we know if that affects GTK+3 as well?
*** Bug 774012 has been marked as a duplicate of this bug. ***
*** Bug 784931 has been marked as a duplicate of this bug. ***
*** Bug 720086 has been marked as a duplicate of this bug. ***
*** Bug 710009 has been marked as a duplicate of this bug. ***
So Ell has found the issue in GTK's GDK code, a one-line change at the point where GDK tries to determine what window an event is supposed to go to. I didn't ask for the specific line, so the following is my own interpretation and any errors are on me. The window lookup happens in _gdk_windowing_window_at_pointer https://git.gnome.org/browse/gtk+/tree/gdk/win32/gdkwindow-win32.c?h=gtk-2-24#n2748 This skips windows if they are e.g. invisible. It does not skip transparent windows yet, though: https://git.gnome.org/browse/gtk+/tree/gdk/win32/gdkwindow-win32.c?h=gtk-2-24#n2764 Adding CWP_SKIPTRANSPARENT to the call to ChildWindowFromPointEx should be the approach to try, unless this has consequences I'm not aware of (which are plenty): https://git.gnome.org/browse/gtk+/tree/gdk/win32/gdkwindow-win32.c?h=gtk-2-24#n2780 https://msdn.microsoft.com/en-us/library/windows/desktop/ms632677(v=vs.85).aspx
Ay, schumaml beat me to the punch :) See bug 658842, comment 15.
I jotted down this as the bug to justify another - possibly the final - 2.8.x release. Provided that we can persuade GTK+ do do another 2.24.x release with any changes, if those turn out to be correct in the first place.
> Provided that we can persuade GTK+ do do another 2.24.x release with any changes For info, we really need a new release for other fixes (related to Windows issues as well) too. Actually even our configure script already has a warning advising to install GTK+ 2.24.32, but this version has not been released yet! Currently, shortcuts with non-latin languages are broken (bug 769550) and vector icons are disabled (bug 781020). So even if that fix was not to get included, a new GTK+ 2.24.x release would be worth it (of course if we *also* had this fix as well, this would be even cooler because that's quite a long running issue now).
I pushed a gtk patch to master that should, hopefully, fix this. I'll include it in 2.9.8, so that we can get it tested. commit fb5354c9e55a789f0b908d7361fdc41c70e08d57 Author: Ell <ell_se@yahoo.com> Date: Sun Oct 29 15:08:07 2017 -0400 Bug 780979 - Fullscreen windows with WS_EX_NOACTIVATE | WS_EX_TRANSPARENT ... ... interfere with GIMP UI events Add a GTK+ patch to ignore top-level transparent windows when looking for the top-level GDK window at a certain pointer location, in the Win32 GDK backend. build/windows/patches/gtk+-2.24-bug780979.patch | 32 ++++++++++++++++++++++++++++++++ 1 file changed, 32 insertions(+)
Is bug 658842 the corresponding GTK+ bug? I see a patch there but it's different from yours. If yours is better, could you propose it and write down that we need it for GIMP?
The patch in bug 658842 is already committed, and is, in fact, what caused this issue (while fixing another one) :) I mentioned our issue in comment 15 on that bug (without a patch, but the patch does exactly what the comment says.)
The above patch has been applied in the Windows build of GIMP 2.9.8. Everyone who has reported relevant issues: please download and test the 2.9.8 Windows version, check if it solves your problem, and report back. We need your input! Thanks :)
Longtime fan, first time writer. I'm on Windows 10 Pro. I was on 2.8.22 and was getting the non-working dockable items (and layer reorder) bug. I moved to 2.9.8 this morning. The issue persisted so i decided to close all other apps and reopen gimp - now works even with all the other apps open. I've tried recreating everything as i had it this morning to see if i could break it and it's worked perfectly since. Finally, for funsies, i restarted my computer, started everything i had open previously before starting GIMP and it worked well. So it appears to be working...i'll update this if anything changes for me. Thanks devs for an awesome product.
The initial persistence of the issue worries me, though.
*** Bug 764008 has been marked as a duplicate of this bug. ***
(In reply to Michael Schumacher from comment #18) > The initial persistence of the issue worries me, though. just as a follow up, i've used GIMP 2.9.8 over the past week with no issues since the initial time i ran it (as noted on 12/22)
I'd say we can close it. Even if it persisted once, the issue still disappeared at next GIMP start without needing any more complicated action. I think that's good enough for an issue which bothered us so much for years. Now if you really think this should investigated, suit yourself. So I leave it opened for now. :-)
*** Bug 792078 has been marked as a duplicate of this bug. ***
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gimp/issues/1082.