Version: (using Devel) Installed from: Compiled sources If two windows are siblings of each other (both top-level) and owned by the same process, KWin treats them as one even though they are actually separate windows. How to reproduce: (With translucency DE plugin enabled and focused != unfocused) 1. Open Dolphin 2. Open another Dolphin window (Dolphin keeps itself to one process) 3. Try to get one window to be at the focused setting and the other at unfocused This makes it hard to use translucency as I do (see multiple windows at the same time without messing around with sizes all the time) since all are at "focused" (100% here) and opaque. Other apps that have similar problems: Firefox KWrite + KWrite via Ctrl+N Should this instead be filed against each KDE app? If so, what to do about Firefox? I'm sure separate processes isn't seen as a step forward in that camp.
I can confirm that the kwin translucency plugin does not detect inactive windows properly when two of the same program are open, eg two konsoles. The dim inactive plugin suffers from the same problem, but is less noticeable.
I can confirm that the kwin translucency plugin does not detect inactive windows properly when two of the same program are open, eg two konsoles. The dim inactive plugin suffers from the same problem, but is less noticeable. This is using KDE 4.1.96 on gentoo.
If I've correctly understand the problem, I cannot reproduce with KDE 4.5.2: I've two dolphin windows and the "inactive windows translucency" enabled, when I select one of the two dolphin windows, the inactive is correctly translucid.
to me (4.5.2) the bug exists, but it's hard to impossible to fix from kwin. all dolphin windows share a common client leader what makes kwin think that they're like parts of the same group. this actually makes some sense, think of eg. TheGimp where you'd usually want the image as well as the docks either "activated" (opaque) or not ...
I'm not all that familiar with how X structures its data internally, but would it be possible to chase window parents up to the root, and then group all windows under the window that's a direct decendent of the root as one? Not sure if this would still group same-process windows as one or whether GIMP windows are all top-level windows.
yes, but a) i don't think this is intended (but to really have all related windows at the same state - think of floating QTdockWidgets & QToolBars) b) i don't see any good reason why all dolphin windows should share a common group leader (since from this report there's obviously no demand to treat them as one) Since this is apparently an autofeature of Qt (kwrite ctrl+n stays in the same process and i guess Qt just hooks all toplevel windows of one pid to the same "virtual" leader - what "usually" makes sense) the clients in question will unfortunately have to unset the client leader... hmmm.. the effect could check for !normal window types in the group (would be heuristical, but maybe "better" than atm. - unfortunately one of gimps docks could be set to that type as well =\ )
given the analysis of comment #6 this is not a bug but a feature request to add some heuristics into the translucency effect. I'm not sure whether we will ever extend the effect though. I think a proper fix should be done inside Qt.