GNOME Bugzilla – Bug 563346
Focused image window jumps behind other program windows (WinXP)
Last modified: 2018-02-10 03:32:56 UTC
Please describe the problem: Odd window behaviour was introduced in 2.6.2, if I recall correctly. The problem consists of the image windows jumping below/behind other program windows while still in focus. Steps to reproduce: 1. In Windows Explorer, right-click an image file, select "Edit with GIMP". 2. Now click the GIMP/image button in the task bar to focus and bring GIMP to the foreground. 3. Perform an action with the image window - move it or resize it using the mouse. 4a. Minimize and then maximize the GIMP image window by clicking twice on the taskbar button. 4b. Instead of step 4a, do this: Assuming the Explorer window does not completely cover the upper part of the GIMP image window, move the image window around while it is below/behind the Explorer window. Now try minimizing and maximizing the image window by clicking twice on the taskbar button as in 4a. the image window will stay behind the Explorer window. Actual results: 1. The image (and GIMP, if it is not already running) will open in the background - Explorer will stay focused and in the foreground. 3. When you let go of the mouse button, the image window stays focused, but jumps behind the Explorer window. 4a. At this step the image window behaves as it should - it stays in the foreground - although always below the GIMP Tools and Layers windows (this may be an user definable feature, and not a bug?). 4b. The image window will stay behind the Explorer window even after minimizing and maximizing it. In order to move it to the front, you have to either minimize the Explorer window, or clicking the GIMP Toolbox or Layers window. Expected results: 1. The image and Gimp should be opened focused and in the foreground. 3. The image window should stay focused and in the foreground. 4a. The image window should stay focused and in the foreground. 4b. The image window should stay focused and in the foreground. Does this happen every time? Yes Other information: Introduced in 2.6.2.
I can confirm weird behaviour of GIMP windows on Windows XP SP3. But it is actually kind of "inverted" for me: The image window (and the tool box with all the icons in it) stays on top all the time, dialogs, including tool windows, file selectors, messages, pop under the window and cannot be put on top. This results in very awkward moving around and resising of windows, just to be able to use the dialogues. Very inconvenient. As bad as it is for everyday work, I am considering downgrading to an older version. Best regards Andreas
The problem in comment #1 seems to be different from the problem of this bug. Please do not make bugs unusable by adding unrelated information, open new ones instead.
Hi Michael, I am not sure this is unrelated. I made my comment because I got the impression it was. I may be wrong, of course. Regards Andreas
I can reproduce this bug exactly as stated. In fact, I have problems NOT reproducing this bug. I have encountered this bug as stated since version 2.6.0. It's so bad that I need to minimize or close every other window in order to use gimp. Sometimes if I repeatedly click any one of the gimp window icons in the task bar, (making it maximize and minimize over and over) suddenly all gimp windows will come to the front. This got so annoying I downgraded back to 2.4.7 Please address this issue when you are able, as I love the improvements of the 2.6.x line, but this bug makes them not worth the hassle. I can't afford to have everything except gimp minimized while I'm working. If it helps the issue at all, the problem seems to be exacerbated when I have a ton of gimp image windows open. I usually have 5-15 gimp image windows open at the same time as other applications. The computer is plenty responsive, the gimp window simply refuse to appear on top of any other windows. Thank you for your time and consideration.
*** Bug 564837 has been marked as a duplicate of this bug. ***
*** Bug 574030 has been marked as a duplicate of this bug. ***
Im encountering this bug to. Im encountering the same behivor mentiond in this bug but also sometimes no gimp window comes to focus at all. I also noticed right clicking the taskbar entry causes gimp to come to the front.
I am encountering similar behaviour on Windows Vista (Home Premium). 1. Every time I open an image from GIMP (i.e. using Ctrl+O or File>Open...) it opens behind the current image. It should focus the image straight away. 2. If I minimise an image window then then click that image in the taskbar, the image is nowhere to be seen. Note that the taskbar button is focused and I can use keyboard shortcuts - if I do, the image will jump to the front. From the look of it, when a GIMP window is minimised, it first gets hidden behind all other windows, then minimised. If you have a maximised window behind the GIMP image window (e.g. Firefox), then the image window disappears when minimising. However, with only the desktop behind the image window, you can see the minimize animation occurring. ** Maybe that image-hiding is the reason for the bug? **
I doubt this is a problem in GIMP, more likely it is a GTK+ Win32 backend problem, reassigning accordingly.
@Martin: OK, but I have never experienced this in any other GTK apps such as OpenOffice or Pidgin, so it's possibly a combination of both GIMP and GTK.
OpenOffice is not a GTK+ application. As for Pidgin, are you sure that the same version of GTK+ is used by (bundled with) Pidgin as your GIMP?
Pidgin says I'm using GTK+ Runtime 2.12.9. GIMP doesn't say anywhere in the app, but under Program Files\GIMP-2.0\lib\gtk-2.0 there is a folder "2.10.0" so I'm assuming that's the version I'm using? If that's the case, it's possible that the bug is fixed in a recent GTK+ version. However, since Pidgin doesn't use many windows, it may not be the case. Is it possible to upgrade the version of GTK+ I'm using in GIMP? [Side note: shouldn't these apps install a shared version of GTK, rather than multiple separate installations?]
No, the existence of a folder called 2.10.0 does not indicate that would be the version of GTK+ it is in. I assume GIMP comes with a recent version of GTK+, 2.16.something, or at least 2.14.x. You should be able to check by right-clicking and looking at the Properties:Version of some of the GTK+ DLLs, like libgtk-win32-2.0-0.dll. The code that is related to handling transient windows etc has changed relatively recently, and likely is different in Pidgin's quite old 2.12.9. But I am not sure if that has any relevance anyway, as there is nothing that says Pidgin would even use similar GTK+ calls to handle window relationships (or more properly, to tell the window manager how to handle the relationships of its windows) (in the Windows case, much of that logic which the window manager handles on X11 is instead then implemented in GTK+ itself, in the Win32 GDK backend). But isn't the normal way to use Pidgin to have just one window with conversations in different tabs anyway? You could always hide away Pidgin's copies of the GTK+ DLLs and copy GIMP's there instead, and see if anything changes in Pidgin's behaviour. Just out of interest.
I can't believe that a bug that makes the entire 2.6 branch of gimp unusable on windows in a production environment would be marked minor and would be unaddressed for approaching a year now. I appreciate the gratis work that these programmers do, but my entire team is unable to use the latest iteration of gimp (2.6.x) and hasn't been able to since the release of 2.6.0. This branch brings lots of improvements, but the window sorting/ordering/focus is completely messed up. I tried it again yesterday and in addition to the behavior reported here sometimes a window will minimize automatically and refuse to return. For instance, when I add some text, the entire toolbox wont come back until I close the text editor. There seems to be something completely broken as relates to window management in GIMP on the windows operating system. I understand that there seems to be little interest in fixing this. It's probably a very annoying bug deep in some twisted piece of code. I just hope I will be able to enjoy the latest minor revision of GIMP in my company at some point :)
Stephen, seriously, you have a "team" using GIMP on Windows in a "production" environment, i.e. for paid work? You are betting your business success on software that has no support and which is known to behave oddly especially on the platform you are using? I don't think anybody who knows GIMP on Windows more closely would have recommended you do that. I am sad to say this, but you should use some proprietary software if you want reliability on Windows and support. Or, use Linux if you want GIMP to behave as the developers intend. Or fund some developer to work on GTK+ on Windows (which is where the window management problems actually are), or tell your favourite open source -friendly software company that you would be prepared to pay for a supported version of GIMP (including thus the GTK+ stack) on Windows.
*** Bug 597774 has been marked as a duplicate of this bug. ***
I haven't experienced this problem with GTK+ 2.18 yet.
We're moving to gitlab! As part of this move, we are closing bugs that haven't seen activity in more than 5 years. If this issue is still imporant to you and still relevant with GTK+ 3.22 or master, please consider creating a gitlab issue for it.