After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 565459 - newly opened images are put into the background
newly opened images are put into the background
Status: RESOLVED FIXED
Product: GIMP
Classification: Other
Component: User Interface
2.6.3
Other Linux
: Normal normal
: 2.6
Assigned To: GIMP Bugs
GIMP Bugs
Depends on:
Blocks:
 
 
Reported: 2008-12-23 14:21 UTC by Maciej Pilichowski
Modified: 2010-06-23 18:22 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Quick hack (726 bytes, patch)
2009-08-19 11:19 UTC, Massimo
needs-work Details | Review

Description Maciej Pilichowski 2008-12-23 14:21:11 UTC
Please describe the problem:
See steps below.

opensuse 10.3, KDE 3.5.10.

Steps to reproduce:
1. run gimp
2. open image A
3. maximize window with image A
4. open image B
5. the active image is B, but the foreground window is with A


Actual results:
The windows are "mixed".

Expected results:
The newly opened image is active and put into foreground

Does this happen every time?
Yes.

Other information:
It is even more confusing when you open not two, but more images, and not one by one, but at the same time.

I doubt it is KDE issue, because other apps have similar UI to gimp, openoffice for example, and there initial putting window into foreground works fine.
Comment 1 Michael Schumacher 2008-12-23 15:12:45 UTC
Duplicate of bug 564837, probably.
Comment 2 Sven Neumann 2009-01-06 23:06:47 UTC
It's definitely a problem of the window manager as that is the instance that decides about the z-order of windows. But unfortunately it seems to be a common problem and we should check if there's anything GIMP could do differently to improve this.
Comment 3 Massimo 2009-08-19 11:19:55 UTC
Created attachment 141147 [details] [review]
Quick hack

It seems that unsetting the 'transient-for' property
of the dialog before destroying it fixes the problem. 

But obviously more testing is needed.

I considered the following test-cases: 

with one image open and maximized

- Open 1 image.
- Open 2 images.
- Trying to open 2 files the second of which in a format 
       not recognized by Gimp.

patch against 'app/dialogs/file-open-dialog.c' of the 
release 2.6.7.
Comment 4 Martin Nordholts 2010-06-23 18:13:09 UTC
Thanks Massimo, I found what I'm pretty sure to be the proper fix based on your investigation:

commit f6781d15c4c253f1b14093e8758504c84f504886
Author: Martin Nordholts <martinn@src.gnome.org>
Date:   Wed Jun 23 20:17:37 2010 +0200

    Bug 565459 - newly opened images are put into the background
    
    When we are going to open new image windows, unset the transient
    window. We don't need it since we will use gdk_window_raise() to
    keep the dialog on top. And if we don't do it, then the dialog
    will pull the image window it was invoked from on top of all the
    new opened image windows, and we don't want that to happen.
    
    Patch heavily inspiried by hack from Massimo Valentini.
    
    Also add a manual test case for the fix. (I don't think there is GTK+
    API to automate it).

I'll cherry-pick this into 2.6 too.
Comment 5 Martin Nordholts 2010-06-23 18:22:27 UTC
gimp-2-6:

commit 3222c3df322b8f892f6ae3758ba7d7e9e996c8fb
Author: Martin Nordholts <martinn@src.gnome.org>
Date:   Wed Jun 23 20:17:37 2010 +0200

    Bug 565459 - newly opened images are put into the background
    
    When we are going to open new image windows, unset the transient
    window. We don't need it since we will use gdk_window_raise() to
    keep the dialog on top. And if we don't do it, then the dialog
    will pull the image window it was invoked from on top of all the
    new opened image windows, and we don't want that to happen.
    
    Patch heavily inspiried by hack from Massimo Valentini.
Comment 6 Martin Nordholts 2010-06-23 18:22:51 UTC
Review of attachment 141147 [details] [review]:

Modified version committed.
Comment 7 Martin Nordholts 2010-06-23 18:22:52 UTC
Review of attachment 141147 [details] [review]:

Modified version committed.