Bug 307125

Summary: Closed Windows stay in dock apps like AWN and docky with desktop-effects enabled
Product: [Plasma] kwin Reporter: Michi <miste78>
Component: effects-variousAssignee: KWin default assignee <kwin-bugs-null>
Status: RESOLVED FIXED    
Severity: normal Flags: thomas.luebking: ReviewRequest+
Priority: NOR    
Version: 4.9.1   
Target Milestone: 4.9.2   
Platform: Arch Linux   
OS: Linux   
Latest Commit: Version Fixed In: 4.9.2

Description Michi 2012-09-20 21:29:08 UTC
If a window is closed the Icon for it stays in Avant-Window-Navigator's and Docky's Taskbar until any other Icon in AWN or Docky is clicked.

With disabled desktop effects AWN and docky work perfect.

Reproducible: Always

Steps to Reproduce:
1.Enable Desktop EffectsInstall
2. install and start AWN or Docky
3.open and close a programm

Actual Results:  
Icon for the closed programm stays in AWN / Docky until any other Icon is clicked on

Expected Results:  
after clsoing the programm started in step 3 the icon should disappear in AWN / Docky

Arch Linux x86_64

KDE 4.9.1
Qt 4.8.2
linux 3.5.4
nvidia 304-43

$ lspci
00:00.0 Host bridge: Intel Corporation 2nd Generation Core Processor Family DRAM Controller (rev 09)
00:01.0 PCI bridge: Intel Corporation Xeon E3-1200/2nd Generation Core Processor Family PCI Express Root Port (rev 09)
00:16.0 Communication controller: Intel Corporation 6 Series/C200 Series Chipset Family MEI Controller #1 (rev 04)
00:1a.0 USB controller: Intel Corporation 6 Series/C200 Series Chipset Family USB Enhanced Host Controller #2 (rev 05)
00:1b.0 Audio device: Intel Corporation 6 Series/C200 Series Chipset Family High Definition Audio Controller (rev 05)
00:1c.0 PCI bridge: Intel Corporation 6 Series/C200 Series Chipset Family PCI Express Root Port 1 (rev b5)
00:1c.2 PCI bridge: Intel Corporation 6 Series/C200 Series Chipset Family PCI Express Root Port 3 (rev b5)
00:1c.3 PCI bridge: Intel Corporation 82801 PCI Bridge (rev b5)
00:1c.4 PCI bridge: Intel Corporation 6 Series/C200 Series Chipset Family PCI Express Root Port 5 (rev b5)
00:1d.0 USB controller: Intel Corporation 6 Series/C200 Series Chipset Family USB Enhanced Host Controller #1 (rev 05)
00:1f.0 ISA bridge: Intel Corporation H67 Express Chipset Family LPC Controller (rev 05)
00:1f.2 SATA controller: Intel Corporation 6 Series/C200 Series Chipset Family SATA AHCI Controller (rev 05)
00:1f.3 SMBus: Intel Corporation 6 Series/C200 Series Chipset Family SMBus Controller (rev 05)
01:00.0 VGA compatible controller: NVIDIA Corporation GT218 [GeForce 210] (rev a2)
01:00.1 Audio device: NVIDIA Corporation High Definition Audio Controller (rev a1)
03:00.0 USB controller: Etron Technology, Inc. EJ168 USB 3.0 Host Controller (rev 01)
04:00.0 PCI bridge: ASMedia Technology Inc. ASM1083/1085 PCIe to PCI Bridge (rev 01)
06:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 06)
Comment 1 Thomas Lübking 2012-09-20 21:39:55 UTC
a) does it also happen with compiz / xcompmgr?
b) does it happen with the plasma taskbar or other dockers (like cairo-dock)
c) how does the behavior change (if) when you alter the compositing state via the runtime toggle (Shift+Alt+F12)

FYI, the docker gets the "window got closed" event from the X11 server and no the WM - i've no idea what compositing should have to do with that (except that the dockers might alter their codepath depending on the availability of an effective ARGB drawable)

and FTR, It does not happen in my taskbar implementation and not with the plasma taskbar either here.
Comment 2 Michi 2012-09-21 10:16:59 UTC
a) no, with compiz it does not happen. (xcompmgr not tested)
b) plasma taskbar works fine, cairo-dock shows same beaviour as AWN and docky
c) if I toggle desktop effects off with Shift+Alt+F12 it does not happen, activate effects again with the key-combo -> same problem again

--> It only occurs with KDE Desktop Effects enabled and Kwin as WM  (with all dockers tested)

I tried to disable the effects one by one to see if any single effect is responsible, but no luck.
Only thing that works is to disable effects completely.
Comment 3 Thomas Lübking 2012-09-21 12:07:34 UTC
Comes with the deleted windows (closing animation - fade effect)

The dockers will likely interpret _NET_CLIENT_LIST_STACKING (rather than building an internal list from the events - they probably all use the very same lib code) and since Deleted now got into the stacking order but is no real window (thus does not cause the event driver property updates), this property gets polluted when a deleted is added

@Martin - options:
a) not let it enter the list
b) remove it on destruction (using Workspace::propagateClients(bool propagate_new_clients) through Workspace::updateStackingOrder(bool propagate_new_clients) eventually through a StackingUpdatesBlocker similar to what Client does on destruction)
Comment 4 Martin Flöser 2012-09-21 12:35:49 UTC
On Friday 21 September 2012 12:07:34 you wrote:
> a) not let it enter the list
> b) remove it on destruction (using Workspace::propagateClients(bool
> propagate_new_clients) through Workspace::updateStackingOrder(bool
> propagate_new_clients) eventually through a StackingUpdatesBlocker similar
> to what Client does on destruction)
I think a) is the better solution, though one could consider b) as well, given 
the the window is kind of still around
Comment 5 Thomas Lübking 2012-09-21 13:39:39 UTC
Yes, thank you for repeating the options :-P

Here's variant (a) patch, it's the cheaper approach (cpu-wise)

https://git.reviewboard.kde.org/r/106526/
Comment 6 Michi 2012-09-21 16:33:10 UTC
Rebuilding kde-workspace arch-package with the patch fixed it, thanks for the fast work. :)
Is it the final patch, so i can file a request to apply it on the Arch-Bugtracker?
Comment 7 Thomas Lübking 2012-09-21 16:36:48 UTC
No, Martin has yet not taken a choice (he's atm. likely on the road)
-> Wait until there's a "ship it!" under the RR ;-)

This bug will get closed with the commit and you'll get a mail by that as well.
Comment 8 Thomas Lübking 2012-09-21 16:39:03 UTC
"(thus does not cause the event driver property updates)" - i should probably really read what i have written before sending - oc supposed to be "event driven", ie. trigger release/destroyWindow() ... tsts
Comment 9 Martin Flöser 2012-09-21 20:22:14 UTC
> Is it the final patch, so i can file a request to apply it on the
> Arch-Bugtracker?
no, the patch will get into 4.9.2 once I have reviewed it. There is no need to 
ask for special downstream inclusion of patches. It makes our lives and that 
of our distributions much easier if the software users are running is the one 
with the version number it is supposed to be. Changes mean that a crash trace 
has offsets and that is really difficult to get when you check the code at 
4.9.1 and it doesn't match.
Comment 10 Michi 2012-09-22 01:44:32 UTC
Ok, then l will wait until 4.9.2 is in the arch repos.
Thanks, again. :-)
Comment 11 Thomas Lübking 2012-09-27 20:15:45 UTC
Git commit 2558b01c14864624ea6d204e79c074f80f1e876e by Thomas Lübking.
Committed on 25/09/2012 at 22:46.
Pushed by luebking into branch 'master'.

no non clients in _NET_CLIENT_LIST_STACKING
FIXED-IN: 4.9.2
REVIEW: 106526

M  +5    -3    kwin/layers.cpp

http://commits.kde.org/kde-workspace/2558b01c14864624ea6d204e79c074f80f1e876e
Comment 12 Thomas Lübking 2012-09-27 20:16:09 UTC
Git commit 8109a04b994eaa5c8b1a1b759ee02346032e3125 by Thomas Lübking.
Committed on 25/09/2012 at 22:46.
Pushed by luebking into branch 'KDE/4.9'.

no non clients in _NET_CLIENT_LIST_STACKING
FIXED-IN: 4.9.2
REVIEW: 106526

M  +5    -3    kwin/layers.cpp

http://commits.kde.org/kde-workspace/8109a04b994eaa5c8b1a1b759ee02346032e3125