Bug 172615 - Gimp 2.6 utility windows do not stay on top of the main window
Summary: Gimp 2.6 utility windows do not stay on top of the main window
Status: CONFIRMED
Alias: None
Product: kwin
Classification: Plasma
Component: general (show other bugs)
Version: unspecified
Platform: Compiled Sources Unspecified
: NOR normal
Target Milestone: ---
Assignee: KWin default assignee
URL:
Keywords:
: 178036 178074 (view as bug list)
Depends on:
Blocks:
 
Reported: 2008-10-11 19:23 UTC by lucas
Modified: 2024-06-12 09:29 UTC (History)
19 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description lucas 2008-10-11 19:23:55 UTC
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
Comment 1 lucas 2008-10-21 07:25:35 UTC
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.
Comment 2 Benjamin Schmitz 2008-11-10 19:12:57 UTC
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.
Comment 3 kgw 2008-12-14 13:49:55 UTC
@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...
Comment 4 lucas 2008-12-18 07:49:59 UTC
*** Bug 178036 has been marked as a duplicate of this bug. ***
Comment 5 Ronny Standtke 2008-12-21 00:00:28 UTC
I just run into the same bug. I even can not minimize the GIMP Toolbox window and the Layers, Channels, Paths, ... window. Really annoying.
Comment 6 Ronny Standtke 2009-01-15 13:15:52 UTC
This bug is still present in KDE-4.2rc1. It is one of the many bugs that prevent me from switching to KDE4.
Comment 7 Shashwat 2009-01-15 13:24:51 UTC
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.. 
Comment 8 Felix Möller 2009-01-26 20:36:49 UTC
The same here with openSUSE 11.1 and KDE 4.1.3 and Gimp 2.6.2
Comment 9 Ronny Standtke 2009-01-28 21:19:05 UTC
Unfortunately, this bug is still present in KDE-4.2 final.
Comment 10 Alexia Death 2009-02-01 10:38:17 UTC
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...
Comment 11 Martin Flöser 2009-03-30 23:48:01 UTC
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.
Comment 12 Alexia Death 2009-04-16 12:14:34 UTC
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...
Comment 13 lucas 2009-04-16 13:00:52 UTC
(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.
Comment 14 Martin Flöser 2009-04-16 13:19:29 UTC
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.
Comment 15 Alexia Death 2009-04-16 14:36:37 UTC
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.
Comment 16 Brendon Higgins 2009-04-17 02:19:31 UTC
(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?
Comment 17 lucas 2009-04-17 03:10:27 UTC
(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.
Comment 18 Ronny Standtke 2009-10-31 23:52:39 UTC
I just updated to KDE-4.3.2 (on Kubuntu-9.10) and, too bad, the bug is still there...
Comment 19 Ozan Çağlayan 2010-02-11 18:58:07 UTC
Will there be an improvement for this in the future releases?
Comment 20 FiNeX 2010-10-10 17:45:17 UTC
*** Bug 178074 has been marked as a duplicate of this bug. ***
Comment 21 Ricardo Graça 2010-12-24 13:18:39 UTC
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.
Comment 22 Thomas Lübking 2010-12-25 16:46:36 UTC
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"?
Comment 23 Alexia Death 2010-12-25 17:55:28 UTC
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...
Comment 24 Alexia Death 2010-12-25 17:57:04 UTC
As to what this bug is about... Its about KDE ignoring a sane defacto standard.
Comment 25 Alexia Death 2010-12-25 18:14:53 UTC
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.
Comment 26 Thomas Lübking 2010-12-25 19:48:55 UTC
[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.
Comment 27 Martin Flöser 2010-12-25 21:15:06 UTC
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.
Comment 28 Martin Flöser 2012-03-15 09:49:09 UTC
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.
Comment 29 Andreas Kilgus 2020-02-02 13:09:31 UTC
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.
Comment 30 David Edmundson 2020-02-02 19:17:03 UTC
If you can explain where we explicitly break the spec I will reopen this.

Thomas above explains that we don't.
Comment 31 Bug Janitor Service 2020-02-17 04:33:11 UTC
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!
Comment 32 Andreas Kilgus 2020-02-21 19:10:50 UTC
(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.
Comment 33 Christoph Feck 2020-03-06 11:25:50 UTC
New information was added with comment 32; changing status for inspection.