Bug 176388 - Obscured (background) window behavior
Summary: Obscured (background) window behavior
Status: RESOLVED DUPLICATE of bug 158262
Alias: None
Product: kwin
Classification: Plasma
Component: compositing (show other bugs)
Version: unspecified
Platform: Debian testing Linux
: NOR normal
Target Milestone: ---
Assignee: KWin default assignee
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-11-28 23:57 UTC by Pandu Rao
Modified: 2009-12-11 11:20 UTC (History)
0 users

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 Pandu Rao 2008-11-28 23:57:13 UTC
Version:            (using KDE 4.1.3)
OS:                Linux
Installed from:    Debian testing/unstable Packages

In KDE4, The behavior of the obscured (background) window has changed. Note this only happens when compositing (all desktop effects) is enabled.

First a little background...
In KDE3- Let us say I have windows a, b and c where a is maximized, b is normal size, and c is minimized.

Let us also say that a is in the foreground. When I RMB click on the taskbar entries for b or c and choose close, they are not brought to the foreground before being closed.

This is the correct behavior.

In KDE4, with the initial conditions same as above, the behavior has changed.

When I RMB click on the taskbar entries for the obscured window, that window is first brought into the foreground and then closed (at least it appears to be that way.

Two noteworthy points here:
1. The minimized window does not do this, it is simply closed. and
2. This behavior only surfaces when I use compositing (Aaron Seigo pointed this out. Thanks Aaron!).

KDE3's obscured window behavior is the correct one. Please use that.

Thanks,
Pandu
Comment 1 lucas 2008-11-29 04:00:02 UTC
Dev note: Window stacking order is not being remembered after a window is closed so when an effect (Disabling fade prevents it) references a window it is always drawn on top.
Comment 2 Martin Flöser 2009-12-11 11:20:25 UTC

*** This bug has been marked as a duplicate of bug 158262 ***