Version: (using KDE KDE 3.0.2) Installed from: SuSE RPMs OS: Linux If an application opens a new window, then this new window sometimes does not pop up on the top, but BEHIND the currently active application main window. I have seen this behaviour with windows from different applications, but I can't say exactly under what circumstances it happens. However I can reproduce it with gimp: - open an image in gimp - enlarge the image window so that it covers nearly the full screen - Open e.g. the "levels" dialogue (Right Mouse Button -> Image -> Color -> Levels) - The new dialog window pops up correctly on the top of the screen (until now everything is fine :-) - Close the "levels" dialog window - Open the same dialog window again (Image -> Colors -> Levels) - And now the new dialog window does NOT pop up at the top, but BEHIND the active window. This is especially nasty if the application main window has full screen size, because in this case the new dialog window gets completely hidden behind the main window and you're wondering why you can't see the desired dialog window popping up ... I experienced this problem with SuSE 8.0 and KDE3, I've never seen this behaviour with my previous, old system (SuSE 7.0 with KDE2). Gerhard
Please try with KDE-3.0.3 or 3.1-beta to see if the gimp problem is gone. For other apps, that behavior is related to the new mechanism that avoids new windows stealing focus from windows in which user is active. So, most of the time the popping of windows in background is wanted. The way gimp marks its windows, OTOH, made possible some bugs with gimp and this mechanism. But it should be fixed in current releases.
Subject: Re: New applocation window pops up behind active window 48786@bugs.kde.org schrieb am 06.10.02 18:04:47: > ------- You are receiving this mail because: ------- > You reported the bug, or are watching the reporter. > > http://bugs.kde.org/show_bug.cgi?id=48786 > > ------- Additional Comments From tibirna@kde.org 2002-10-06 18:04 ------- > > Please try with KDE-3.0.3 or 3.1-beta to see if the gimp problem is gone. Thanks for your fast answer. I've planned to upgrade to SuSE 8.1 anyway, which includes 3.0.3. (But I don't think I'll have the time to do it this week). I'll let you know the result. > For other apps, > that behavior is related to the new mechanism that avoids new windows stealing focus from > windows in which user is active. So, most of the time the popping of windows in background > is wanted. You make me curious :-) What are the criteria for deciding whether to open a new window at the top or behind the active window (and particularly if the application explicitly raises the new window)? (Basically, if I e.g. click a button in an application window and as result a dialog window pops up, then I think I rather want to get the new dialog window at the top. But on the other hand I also know the "classic" problem of undesired windows popping up unsolicitedly at the wrong time and stealing the focus ...) Best Regards, Gerhard -- Gerhard F
*** Bug 43102 has been marked as a duplicate of this bug. ***
*** Bug 44168 has been marked as a duplicate of this bug. ***
My first impression with KDE 3.0.3 (SuSE 8.1) is, that my gimp problem with new windows appears to be gone. However, I now also noticed the problem with xv (as reported by Lubos Lunak, #43102) Regards, Gerhard
Should work in KDE3.1.
REGRESSION: KDE_3_2_BRANCH The problem appears to be specific to The GIMP. I have KFM open and open The GIMP in front of it. When I open a new GIMP window it does not get focus. I have to go to the task bar and select them to get focus. -- JRT
This problem appears to be some interaction between: Window Focus Policy Focus stealing prevention level I have the Policy set to: Focus "Strictly Under Mouse" and the other was set to: "Low". If I set the Policy to: "Focus Follows Mouse" the problem goes away. Turning the: Focus stealing prevention level to: "None" fixes the problem. Therefore, priority lowered to: "Normal". -- JRT
This bug report is being changed because the same problem now has a new cause. If you are having the problem with a 3.2 release candidate or with 3.1.4 or 3.1.5 and the cause is not as stated in comment #8, please advise. The problem simply stated is that: "Focus Stealing Prevention" does not work with a Focus::Policy of: "Focus Under Mouse" or "Focus Strictly Under Mouse" If you try to use it with one of those two Focus Policies the window manager's actions are all screwed up. There is a simple work around for this, just turn it off. My suggestion is that since 'Joe user' might not be able to do this that a small change be made to the code so that it is disabled if you choose one of those two Focus Policies. -- JRT
I agree. Focus stealing prevention is now disabled for those focus policies.
I am sorry to report that I am reopening this bug because the problem appears to have returned. I am using 3.3.0 Beta 2 and will check with the RC as soon as I get it up and running. My window behavior settings are: Focus Follows Mouse Auto raise NOT checked Click raise active window NOT checked Focus stealing prevention level: None Test case #1 using Adobe Acrobat Reader to view PDF files. I have set File Associations: Embedding: Show file in seperate viewer Acrobat Reader as the first item in: Application Perference Order. 1. Left click a PDF file and it opens correctly. 2. Left click another PDF file and the new window is not raised. Test case #2 using The GIMP 2.0.2 and the 'desktop' file that comes with it in the menu. Using JPEG files and The GIMP added to bottom of the Application Perference Order window. 1. Right click a JPEG file -> Open With -> The GIMP and it opens correctly. 2. Right click another JPEG file e -> Open With -> The GIMP and the new window is not raised. -- JRT
The problem described in comment #11 is a duplicate of bug #79596, and is something slightly different from the original report -> closing, continued in bug #79596.