Version: (using KDE 4.3.0) Compiler: gcc (Gentoo 4.3.3-r2 p1.2, pie-10.1.5) 4.3.3 x86_64-pc-linux-gnu OS: Linux Installed from: Compiled From Sources Clicking the superkaramba 'peanut' icon to bring up the plasma menu (Desktop setting, unlock widgets etc) causes all open windows to minimize. Once the menu is closed they usually restore, but not always.
*** Bug 202552 has been marked as a duplicate of this bug. ***
yes, it calls "show desktop" when clicked, and again (well, the reverse, "unshow desktop") when either another window appears or it is closed. this allows one to access the desktop layer properly when it is expanded. can you give me a series of steps to replicate the not restoring behaviour, as that should never happen? p.s. we call that thing the Toolbox :)
(In reply to comment #2) > yes, it calls "show desktop" when clicked, and again (well, the reverse, > "unshow desktop") when either another window appears or it is closed. this > allows one to access the desktop layer properly when it is expanded. OK - so I assume this is actually the intended behavior? It's damned annoying, but I guess it's a design decision. > > can you give me a series of steps to replicate the not restoring behaviour, as > that should never happen? To replicate the 'don't restore' behavior, it seems that anything calling a window switch triggers this, e'g' ALT-Tabbing between windows, running expose etc. > p.s. we call that thing the Toolbox :) Thanks - nice to know what it's really called :-).
"but I guess it's a design decision." yes, it is. otherwise you open the toolbox and it goes behind windows or windows obscure the desktop layer ... and by opening the toolbox you're pretty clearly saying 'i want to interact with the desktop layer'. bringing up the context menu by right clicking in an empty space doesn't doe this, of course, but i find that a little less convenient than just zipping to the toolbox (and less pretty too ;) "ALT-Tabbing between windows" hmmm.. this works here properly. i wonder if there's some kwin setting that's getting in the way? *scratches head*
(In reply to comment #4) > hmmm.. this works here properly. i wonder if there's some kwin setting that's > getting in the way? *scratches head* I have desktop effects enabled - would that make any difference? Basically what happens if I trigger a window switch is I get the window (or window-like item) switched-to, and that's it - everything else stays minimized.
hm.. desktop effects aren't _supposed_ to interfere with that feature, but in case it's some interesting configuration that we haven't taken into consideration, could you disable desktop effects on your system and see if you can still trigger this misbehaviour? if you can't, then we'll need to start sifting through which plugins you have enabled in kwin to find the culprit(s). :/
Have tested with desktop effects disabled, and it still misbehaves. What do you need me to do next to track this one down?
Hi. I've reproduced the restoring bug too: 1) open two windows (for example one dolphin and one kcalc) 2) click the toolbox (the 2 windows are minimized) 3) press ALT+TAB and select dolphin -> dolphin window is restored and the kcalc one not The ALT+TAB switcher I'm using is the classical "box" switcher and I'm using kwin default settings. P.S: I'm using trunk compiled yesterday morning, Qt 4.5.2 and a dual monitor setup with nvidia twinview.
This isn't a problem of the cashew, you can get the same problem with the show desktop plasmoid.
Still present in 4.3.1.
Still present in KDE SC 4.4 beta 2. I did: 1. open dolphin and kcalc 2. click the toolbox (they are minimized) 3. ALT+TAB to dolphin (the same as FiNeX) The toolbox menu didn't close when dolphin was restored. Then I tried opening new windows and the toolbox menu didn't close itself when new windows appeared. The only way I was able to close the toolbox menu was to click on it again. That triggered the "show desktop" effect minimizing all the windows that were visible. The menu didn't close yet. Then I clicked on it yet again and it closed restoring the windows that were visible just before that last "show desktop" effect. Using kwin default (I haven't changed anything after creating a new account, at least) settings. Using OpenSUSE 11.2 packages.
SVN commit 1069706 by aseigo: rework the toolboxes so that they actually mesh with the API of AbstractToolBox: * have setShowing call the show/hide feature, not the other way around (fixes bug 202549) * put the actions in order by the tags applied so that things appear ordered * allow the toolbox to define what the parent of the tools should be (so the desktop toolbox can use the backing as the parent) * use a layout in the desktop toolbox background that the tools are in; waaaaaay simpler code as a result * keep only one svg object around for the desktop toolbox background, not two * use a QtKinetic animation for the show/hide i'm not happy with the precise positioning of the desktop toolbox nor with the animation (just a fade in/out right now.. meh) but the hard work is done with this commit and the rest is twiddling (which i'll do in the coming days) BUG:202549 M +123 -226 desktoptoolbox.cpp M +4 -2 desktoptoolbox_p.h M +39 -8 internaltoolbox.cpp M +5 -3 internaltoolbox_p.h M +0 -2 paneltoolbox.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=1069706