Hello at all,
I switched to KDE just some days ago. I upgraded my Fedora and I don't like Gnome 3, so I decided to give KDE a chance again and I must say I like it very much. But there is a gnome (compiz) option I really miss:
When I was working with gimp or other software that has more than one window, I used the "group and tab" plugin to bring the main window and the utility windows all to foreground by just clicking one of them.
In kwin I didn't find an option like this. That won't be any problem cause meanwhile gimp has added a feature to handle the two other windows as utility windows, so that the window manager brings them to foreground together. This works fine with compiz, there is no grouping necessary anymore, but with kwin this won't work. Kwin recognizes the utility windows, e.g. when you activate this option in gimp only the main window will be shown in the show windows effect, but it doesn't bring them to foreground together.
Can anyone tell how to do this? Or is it just impossible in KDE? I also took a look at the window rules, but I didn't find any solution.

AFAIK the GIMP behaviour depends on non standardized behavior of Metacity which had been copied to Compiz. KWin does not have this behavior and it was decided some time ago to not implement it because GIMP 2.8 will come with a sane user interface. Unfortunately the release of GIMP 2.8 took a few years more than expected

With 4.9 it will be possible to use a KWin Script to move all GIMP windows on a new desktop.

...because GIMP 2.8 will come with a sane user interface

I like the multi window user interface and I think only the possibility of using gimp in one window mode is no need to drop support for multiple windows.
Why using a script for moving all gimp windows on another workspace? This works pretty well using the window rules.
Do I understand this right, that there is no way at all to handle those windows as a group?
What does the "autogroup windows in foreground" option in the window rules? I tried to find out what this option does, but couldn't find any documentation?

> there is no way at all to handle those windows as a group
of course there is - make the Gimp developers do so.

there are two independent hints "utility" (window type) and "transient" (basically keeps the window above its main window) in the netwm "spec" which was more or less "dictated" by gnome/metacity developers (following their daily ideas - therefore the entire "spec" has like no concept, but it's the one in use and only one available)

now, gimp has muddled along its window management for the past decade(s - nearly) and at some point in the rather recent past decided than from now on "utility" should imply "transient for the window leader and all it's normal window followers, ie. the part of the group" (and by this introduced an invisible client leader "main window") - to make that clear: the docks are not even marked "transient" for this fake leader window.

compiz "followed" them and has iirc even been asked to at least call for an update of the spec in this regard instead of unilaterally deviating from more or less their own words, needlessly merging two hints, by this implicitly -but clearly- violate the "sepc" and by this pot. breaking other stuff (in terms of "application", not "windowmanager") - they did not

of course, gimp devs could have just handled the transiency gracefully or simply managed restacking/raising their docks themselves instead to gain this result - it is ONE function that needs to be called (ok, "per dock") when activating a window to get this, but hey: why go the simple and portable way?

/rant

you should nevertheless be able to have (in 4.,9) a script that simply raises all gimp windows when activating (or raising) one of them if you don't want to use the single window mode.
Until then the likely best solution is to use a distinct VD and set the docks to keep above

> What does the "autogroup windows in foreground" option in the window rules?
It's for window tabbing - if you did not so far, rather don't use before 4.9 (was introduced with a GSoC and utterly broken - meaning "stackoverflow prone" broken...)

Thank you for your detailed answer. As a user I only see it is not working and don't know about the background why this isn't working. The most simple way would have been to blame KDE for not implementing it, that Gimp and Metacity are violating some standards woldn't have come to my mind. So I think now it is clear why this isn't working and that it's not been caused by KDE.
Good to know that it will be possible in 4.9, unitl then I think I will use it on another workspace, I think that's the most simple solution.