Version: (using Devel) Installed from: Compiled sources Gimp 2.6 relies on utility windows being always on top of main windows of the same application even when a transient hint is not set. Currently Metacity and Compiz provide this. The Gimp developers decided to not provide transient hints in the stable release due to several usability problems they caused [1]. The EWMH specification does not say anything about the stacking order of window types so KWin, Metacity and Compiz are all doing different things in this regard. Earlier this month Compiz changed their stacking order to force utility, menu and toolbar windows to be group transients [2] to workaround this bug. If this is the correct choice and is also added to KWin then I recommend that this stacking order layout should also be added to the EWMH specifications to prevent future problems. The Gimp contact for discussion on this topic is Sven Neumann, a.k.a. neo on irc.gnome.org / #gimp . [1] http://svenfoo.geekheim.de/2005/05/12/transient-docks/ [2] http://gitweb.freedesktop.org/?p=xorg/app/compiz.git;a=commit;h=46e4aa0308fe542f2586835e86ee249ebea6fafb
Raising priority as it's a semi-blocker for 4.2 because it prevents a popular program from working in KDE. The only three available workarounds are: 1) By going into The Gimp's preferences and switching the toolboxes to normal always-on-top windows, but this causes excessive flashing in the task manager and prevents using other applications while The Gimp is running, 2) The same as above except using KWin's special window settings, and 3) Editing The Gimp's configuration file by hand to force the toolboxes to use transient hints. This causes the problems described in [1] in the opening report.
Also, Gimp's utility windows do not maximize/minimize together with the main window. Furthermore, when the main windows gets focus, all utility windows should be brought to front. They shouldn't show up in the task manager as separate windows either.
@Benjamin, now the situation is even more annoying, see bug report #177025, some windows of the GIMP are handled differently in the window lists - utility windows aren't picked up by the main window list in the task panel, the image window on the other hand isn't picked up by the keyboard switching (TAB-key) list. This renders using the GIMP virtually impossible as you can only bring one kind of windows to the top via the panel and others only via the keyboard. This all is with a default GIMP install, you need to change the window settings to normal window to get any sort of usable behaviour out of KWin...
*** Bug 178036 has been marked as a duplicate of this bug. ***
I just run into the same bug. I even can not minimize the GIMP Toolbox window and the Layers, Channels, Paths, ... window. Really annoying.
This bug is still present in KDE-4.2rc1. It is one of the many bugs that prevent me from switching to KDE4.
Too bad. If this won't get fixed I might not switch to KDE 4.2 :( I thought this would have been fixed for 4.2 :) Please guys do fix this up..
The same here with openSUSE 11.1 and KDE 4.1.3 and Gimp 2.6.2
Unfortunately, this bug is still present in KDE-4.2 final.
Is somebody working on this? This is the last bit of poo ruining the dish that is KDE 4.2 for me. Running metacity as wm costs me notifications and all that kwin eyecandy... :/ If theres a patch to test Im more than willing...
changing to wishlist, as it's not really a bug, but would require a change of currently intended behaviour. AFAIK nobody is working on this issue. Personally I'm opposed to the idea that we work around changes of applications which rely on not standardized behaviour of other window managers.
You must be kidding... It is a usability bug and a major one. Its one of the biggest and most annoying issues I face daily using and developing GIMP on KDE. If you refuse to fix it in kwin, please tell us how same effect can be achieved without breaking anything for other wm-s and creating a hack in GIMP to fix the problem. Transient docks (I use dev version, so I have them enabled) is simply too mystifyingly buggy. At times all docks disappear and it takes several minimize-maximize events to get them to show again, random docs are and are not listed in task bar etc...
(In reply to comment #11) > AFAIK nobody is working on this issue. Personally I'm opposed to the idea that > we work around changes of applications which rely on not standardized behaviour > of other window managers. The layer order of utility windows is not specified at all in the standards therefore there is no "standardized behaviour" at all and each and every window manager is doing the right thing in that regard. I agree that it's a wish but I do not agree that we should not implement it. KWin is currently the only major window manager that does not layer such windows above their parent so if we do make the change then it pretty much becomes the standard way of doing it. I have tried to fix this myself but as KWin's layering code is far more complex than other window managers I have failed in producing a working patch.
ah what I should have added: I don't oppose to getting this fixed. I just wrote down my personal opinion which is neither the opinion of all kwin devs nor does it tell what I will implement or not. I just don't like workarounds for applications. About working on it: like Lucas I'm probably not able to produce a working patch and I would not even start to work on it as I don't use applications like GIMP (I don't like such structured UIs) and by that would not be able to know how the user expects the behavior.
I am personally willing to test/collaborate with anybody who has a clue what to do to get the expected result and can provide the expectation. I can easily patch and build things.
(In reply to comment #13) > KWin is currently the only major window manager that does not layer such > windows above their parent If that's true, isn't that the definition of a de facto standard?
(In reply to comment #16) > If that's true, isn't that the definition of a de facto standard? That was the word I was looking for. Yes, if KWin does it then it becomes de facto.
I just updated to KDE-4.3.2 (on Kubuntu-9.10) and, too bad, the bug is still there...
Will there be an improvement for this in the future releases?
*** Bug 178074 has been marked as a duplicate of this bug. ***
Two years later and still no progress. This is still present in kde 4.5.4. I wish I could vote +1000 on this one.
vim ~/.gimp-2.6/gimprc append "(transient-docks yes)" (w/o quotes, w/ brackets) --> toolboxes do what "transient" is supposed to do and stay above the leader which gimp will pass around to the currently focussed image. this works since ages here, so i just wonder: -> "what precisely is this bug all about"?
Development builds have a toggle for it in properties. It is disabled for a reason. It's buggy as hell in most DE-s. Admittedly I haven't tried it in latest KDE, because of horrible experiences previously. It doesn't change the fact that KDE does the stupid thing about utility window hints and puts the utility windows under main window and makes it impossible to run gimp alternatingly in both kde and gnome without reconfiguring it...
As to what this bug is about... Its about KDE ignoring a sane defacto standard.
I took a look and guess what, The option is gone in GIT 2.7 branch since 2009-07-21 with an explanation that the right way to get this done is utility window hints apparently.
[I managed to remove a comment about those claims] There is an *explicit* ICCCM standard hint to signal a leader (to stay above) (WM_TRANSIENT_FOR), and not even a suggestion about the utility window layer, but instead a statement: "_NET_WM_WINDOW_TYPE_UTILITY indicates a small persistent utility window, such as a palette or toolbox. [...] Windows of this type may set the WM_TRANSIENT_FOR hint indicating the main application window." in the NETWM standard (that was afaik and btw. mostly written by/towards the gtk/gnome fraction - not at all a complain from my side, just mentioning) Then ONE application (gimp) thinks to not use the property suggested in the NETWM standard (for what reason ever) but /expects/ sth. rather unrelated and unmentioned. Now, instead of calling for a standard alternation, compiz was just modified to and _only_ to fit this behaviour, not excatly breaking the standard (since there's no hint about the utility layer) but introducing an unnecessary restriction and that should be called "/sane/ 'de facto' standard"? Personally, I don't care too much about the utility layer, but: --------------------------------------------------- a) there might actually be complementary clients who relied on the defined standard and will fail on such _new_ restrictions. b) there's actually no real point (but gimps "will") in reducing this degree of freedom (merge two independent hints in one) c) if there actually was (like "for broken implementations"...), the proper approach was to either alter the pretty much self-defined standard (and /especially/ strike the then more than misleading "may set the WM_TRANSIENT_FOR" part) or extend it by some "ON_TOP_OF_GROUP" hint - instead of expecting everyone to break the standard the same way (to -sorry- fit gimp's WM requirements de toujours, they changed quite some times in the past...), because /that/ is certainly not the definition of a "standard" - neither actual, nor "de facto". Period.
one thing to add to the points mentioned in comment #26 GIMP nowadays supports a single window interface. There is no point in breaking the standard any more. I am against adjusting KWin core to the needs of one application. I also want to add that KWin in 4.6 has a JavaScript binding. I think it is possible to implement the required functionality in a script. If it is not possible the interface can be extended and I would even consider this as a bugfix. Fixing broken applications is exactly what the scripts are for.
after two more years with nobody working on it and gimp getting closer to the single window interface I think it's finally time to properly state that we won't adjust KWin to the needs of one specific application.
According to https://manual.ardour.org/ardour-configuration/system-specific-setup/kde-plasma-5/ - if their claim about the behaviour of other window managers is valid - gimp is not the only application that reads the ICCCM standard a different way compared to kwin (and looking at the age of this bug report still compared to the one of Plasma 5). So it does not seem to be one application kwin had to be adjusted to but one window manager that behaves different to all the others - at least in this small but not completely irrelevant case of utility windows. Perhaps this is the reason, too, why I sometimes have to dig for message and dialogue windows behind the main window of applications running with wine. But this just came to mind while typing, I have no prove for it being another instance of the same problem.
If you can explain where we explicitly break the spec I will reopen this. Thomas above explains that we don't.
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please mark the bug as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone!
(In reply to David Edmundson from comment #30) > If you can explain where we explicitly break the spec I will reopen this. I am no specs expert but I can tell if something works as expected. Below you find the test results of several window managers. Work as expected (plugin gui opened in ardour/mixbus stays in foreground): compiz openbox metacity xfwm4 Work in an alternative, usable way (plugin gui does not stay in foreground in every case of user interaction with main window but the plugin gui is always just an Alt+Tab away because it is part of the windows list): icewm fvwm fvwm2 Main window of ardour/mixbus must be minimized or synth gui must be closed and reopened for the synth gui to be accessible, no return via Alt+Tab: kwin > Thomas above explains that we don't. So if the conclusion is already set there's no need to discuss. My private conclusion: I will have to switch to another window manager that you may claim not being standard-compliant - though I wonder at so many window managers seeming to belong to this group if your claim is true, see above - but that keeps windows accessible at least.
New information was added with comment 32; changing status for inspection.