|Summary:||Keep window thumbnail "Always" breaks minimizing windows|
|Product:||[Plasma] kwin||Reporter:||Chri <christoph>|
|Component:||compositing||Assignee:||KWin default assignee <kwin-bugs-null>|
|Severity:||normal||CC:||alecm, alejandronova, andresbajotierra, andrew.dorrell, broken.zhou, godutchnow, kde_bugzilla_2, l.arvanitis, vo.zaeb, vovochka13|
|Latest Commit:||Version Fixed In:|
Description Chri 2009-04-12 09:46:30 UTC
Version: (using KDE 4.2.2) OS: Linux Installed from: Ubuntu Packages Hi, I installed Adobe Air ( 1.5.1) on my 64bit Kubuntu 8.10 KDE 4.2.1 (now on 4.2.2). Air applications run fine until I minimize them to tray (twhirl, tweetdeck). If I then try to restore it, my Desktop (Kwin) comes unreaktive (seems like Twhirl is restoring from the "systray" then minimizing to it again in and endless, fast loop), can't even switch applications anymore (have then to kill the AIR process from another tty command session) If I turn compositing (desktop effects) off, everything works as it should. I started a thread in following forum and another user experienced the same http://forum.kde.org/adobe-air-crashes-kde4-2-kwin-t-36510.html#pid50964
Comment 1 Dario Andres 2009-04-12 15:56:04 UTC
If this seems to be a KWin issue, reassigning to it.
Comment 2 lucas 2009-04-12 16:00:52 UTC
What is the value of System Settings -> Desktop -> Advanced -> Keep window thumbnails? Does it still occur if set to "never"?
Comment 3 Chri 2009-04-12 18:11:35 UTC
Keep window thumbnails -> never solves the problem.
Comment 4 lucas 2009-04-13 05:48:26 UTC
What was the original value? If it was "always" then this is a WONTFIX as there is no way to fix it without changes to X.
Comment 5 Chri 2009-04-13 06:25:59 UTC
yes it was "always". would be good if this goes somewhere into an official documentation.
Comment 6 lucas 2009-04-13 07:51:27 UTC
Not closing yet as more research is needed to see if there is any way KWin can work around the problem.
Comment 7 lucas 2009-04-13 08:25:23 UTC
SVN commit 952987 by lmurray: State in the GUI that minimization breaks when always keeping taskbar thumbnails updated. CCBUG: 189435 M +1 -1 main.ui WebSVN link: http://websvn.kde.org/?view=rev&revision=952987
Comment 8 Martin Flöser 2009-04-13 10:48:29 UTC
*** Bug 181848 has been marked as a duplicate of this bug. ***
Comment 9 Martin Flöser 2009-04-13 12:17:37 UTC
*** Bug 189292 has been marked as a duplicate of this bug. ***
Comment 10 Lubos Lunak 2009-04-17 19:36:09 UTC
Always having thumbnails for a window means the window can never be unmapped (in X11 terms). Which is the common way to implement minimizing. I assume the application gets confused by the fact that its attempt to minimize the window don't "work" and gets stuck in a loop. Yet another proof systray sucks and apps should not play with window management. Maybe some ugly hack can be added to KWin to prevent such loop.
Comment 11 Martin Flöser 2009-04-28 10:04:41 UTC
*** Bug 184556 has been marked as a duplicate of this bug. ***
Comment 12 andrew 2010-03-05 12:13:14 UTC
I turned on "always" because I use present windows and its pretty awkward otherwise. I have not noticed any problems with minimisation. Is this bug still valid? Platform Version 4.4.1 (KDE 4.4.1)-kdemod on Arch Linux.
Comment 13 Alejandro Nova 2010-07-01 06:47:37 UTC
I vote NO. I'm even for reverting this bug. Under KDE 4.5, I actually have a better minimization with Keep Window Thumbnail set to Always. The bug reversion would be like this. "Keep Window Thumbnail - Always does not break minimizing windows anymore: Please, remove the string suggesting brokenness, since it doesn't applies anymore". Although I'm testing with KDE 4.5 RC, the KDE 4.4 line already fixed this for me. Please, close this as FIXED and remove the string "brokes minimization" in "Always" setting.
Comment 14 Martin Flöser 2010-07-01 17:54:23 UTC
> "Keep Window Thumbnail - Always does not break minimizing windows anymore: > Please, remove the string suggesting brokenness, since it doesn't applies > anymore". This is impossible. It is a technical limitation of the underlying X stack and this limitation will probably never be fixed. It is possible that you do not experience the problems, nevertheless it is likely that some apps are broken.
Comment 15 Alexander 2011-04-27 13:12:50 UTC
This bug is one of the most annoying bugs, for me...
Comment 16 Thomas Lübking 2011-04-27 20:35:23 UTC
The bug as described originally is -iff at all- on adobes side (acts on _assumed_ state/ability) It's however reasonable since usually one can minimize a window on X11. So the "correct" behavior was to NOT choose the "always" setting (which is not default in vanilla kwin either) - with the effect that "minimized" windows are lost for the compositor (thus the blank/black windows in certain conditions) To "fix" this one would need a refinement of X11 protocols / the NETWM standard - and that changes would have to be reflected by the clients (in this case adobe air) as well. (so they could as well fix the false assumption which leads to buggy behavior) The issue would be resolved by alternative display servers (such as wayland) which use offscreen rendering for all clients by design (but of course you'll then as well require a compliant client from adobe for wayland...) The bug is open because lucas then thought one could have a better solution, but i guess it's rather a "wontfix" - you can still choose whether you prefer true minimization or glitch free effects. Sorry :-(
Comment 17 Martin Flöser 2012-04-09 07:19:14 UTC
*** Bug 227120 has been marked as a duplicate of this bug. ***
Comment 18 Yichao Zhou 2013-08-21 03:19:31 UTC
May I ask what does "Keep window thumbnails" do for these three options?
Comment 19 Thomas Lübking 2013-08-21 09:22:46 UTC
(In reply to comment #18) > May I ask what does "Keep window thumbnails" do for these three options? It prevents the window from being actually unmapped when eg. on a different desktop or - in the "always" case, even when minimized in order to provide a "live preview" of the window.
Comment 20 Thomas Lübking 2015-07-06 21:00:37 UTC
This "bug" is a friction between clients with buggy/optimistic/aggressize iconification implementation and unmapped windows not bein drawables (nor updating) - clients should not go wild if they don't get unmapped for an iconification, but from the compositors POV and on X11 this is a conflict that _cannot_ be resolved. An unmapped client cannot show a live update, so if you want a live preview, you must not unmap the window - if the client cannot deal with that, that's a client problem. tl;dr - truth is: WONTFIX, sorry.