Version: (using KDE 4.4.0) OS: Linux Installed from: Ubuntu Packages I suggest implementing a "show desktop" effect for kwin: If the effect is enabled, whenever the user triggers some keyboard shortcut, all windows on the current desktop move aside so that the user is able to interact with plasmoids on the desktop. When the user triggeres the shortcut again, the windows move back to their original place. Compiz has a similar effect (though I presently don't remember how it is called) which moves the windows to both sides of the desktop and makes them transparent, so that they are still slightly visible at the borders of the desktop. This works as a hint that the "show desktop" effect was triggered, should the user forget to toggle it back. At the moment, there is a similar functionality provide by the "show desktop" plasmoid. The difference to that plasmoid would be that the visible windows wouldn't get minimized. The plasmoid's "show desktop by minimizing windows" actually isn't working well (see bug #179749), messes two concepts ("minimizing" and "show desktop") and thus confuses users (see bug #191394 for example).
what would be the advantage of such an effect compared to the dashboard (ctrl+f12)?
1. You could place other widgets on the dashboard than on the desktop (this is possible with KDE SC 4.3, but I can't find the option in 4.4...) 2. Dashboard is quite slow, usually takes 2-3 seconds to show (on my admittedly quite old machine...) 3. It feels more natural... Plasmoids are on the desktop, so to use them, I want the windows to go away. Plasma dashboard on the contrary is an additional overlay (desktop -> windows -> dashboard) and so introduces more complexity to the mental model (you have to build a concept of a dashboard containing the same plasmoids as the desktop). As I said, I presume the first thing every new user will try to get to his/her plasmoids covered by windows is to move these windows away...
1. is a valid reason 2. isn't a valid reason - we don't workaround bugs (slowness) by implementing different stuff 3. isn't a valid reason - the dashboard was added exactly for the usecase that you want to easily access the widgets. Honestly, I think the chances that this will be implemented are bad.
2. I agree. 3. I don't agree. It may be that dashboard was designed for this usecase, but then I consider it bad design, for the mentioned reason. IMHO, a more intuitive interpretation of the dashboard would be that it contains different plasmoids than the desktop. That's why it appears *above* the windows and looks different than the desktop (semi-transparent black). That it was designed as a "show my desktop plasmoids" by the ingenious plasma developers doesn't make it good design by definition, IMHO... Plus it makes accessing the plasmoids on the desktop difficult when plasma is configured to have different plasmoids on the dashboard. A kwin effect as suggested by me wouldn't hurt the plasma developers original intentions though. It wouldn't have to be enabled by default, like other kwin effects. And it shouldn't be hard to implement, shouldn't it? Functionality is already there: Triggering kwin effects by shortcut, moving windows around, making windows translucent...
tbh, i'm a little confused by the report. dropping "plasma is slow" and "windows should slide outside FX" - what's the point about this? there's a feature to show the desktop. technically "show desktop" means "minimize all windows", but the desktop is either shown or not, so any break (new window mapping) will toggle it. reading the other bug reports, #179749 & #191394 (dupes?!) read llike "i don't want old windows to re-appear when a window shows up while showing desktop" ... what is a call for a button (plasmoid, whatever) to hide all present (normal) windows (like pressing their minimize buttons), and maybe keep a list outside kwin and restore only the listed windows when toggling the button again. simple thing. (though the attached demo probably won't work) is this it?!
See also https://bugs.kde.org/show_bug.cgi?id=182729. There is posible to assign keybinding in KDE 4.4 using System Settings->Keyboard&Mouse->Global keyboard shortcuts->KWin->Show Desktop
Thanks, Alexander, for mentioning the new shortcut (im still on KDE 4.3, so I didn't know about it). I can't see why "show desktop" technically means "minimize all windows". It's more like "most implementations of a show desktop functionality up to now use the minimize functionality to achieve their goal". And IMHO it's more an "abuse". Consider the case that you already have minimized some windows and trigger show desktop. Now all windows are minimized, some of them get unminimized automatically when some events occur (shortcut triggered again, new window appears, ...). But in "all minimized" state you can't see the difference. It's two concepts mixed up. I would consider a "windows slide to the sides to show desktop" concept as proposed a more natural, organic concept. Just like the "slide back" kwin-effect is a more natural way to change the window stack order. We've got about four different methods (kwin effects) for changing the active window (ALT+TAB), so I don't see any reason why it would hurt if we had one show desktop effect in addition to a "minimize all" keyboard shortcut. So I still hope that somebody will implement it...
Well there is a technical limitation. The effects only change the visual appearance of the desktop. So the windows might be moved away in the effect, but only their visual appearance. The windows itself are still unmoved and so you are unable to interact with the desktop as the mouse clicks are caught by the windows. In consequence to implement such an effect we would have to, hmm let's think... minimize all windows and make it look like they are not minimized. So nothing is won. There's a reason why most implementations of show desktop minimize all windows. Dashboard is really the solution to the problem. And I don't see a reason why we should start to implement a workaround.
(In reply to comment #8) > Well there is a technical limitation. The effects only change the visual > appearance of the desktop. So the windows might be moved away in the effect, > but only their visual appearance. The windows itself are still unmoved and so > you are unable to interact with the desktop as the mouse clicks are caught by > the windows. Then how does the "present windows" effect work? By temporarily minimizing all windows? The compiz plugin I mentioned above lets you interact with the desktop, too. Maybe it's also some kind of minimizing hack... > In consequence to implement such an effect we would have to, hmm let's think... > minimize all windows and make it look like they are not minimized. So nothing > is won. There's a reason why most implementations of show desktop minimize all > windows. If the only way to remove a window from the desktop without closing it is to minimize it, how does shade/unshade work technically? > Dashboard is really the solution to the problem. And I don't see a reason why > we should start to implement a workaround. No it isn't. You said yourself that point 1 (see comment #2) is a valid reason.
(In reply to comment #9) > (In reply to comment #8) > > Well there is a technical limitation. The effects only change the visual > > appearance of the desktop. So the windows might be moved away in the effect, > > but only their visual appearance. The windows itself are still unmoved and so > > you are unable to interact with the desktop as the mouse clicks are caught by > > the windows. > > Then how does the "present windows" effect work? By temporarily minimizing all > windows? In present windows you are unable to interact with the desktop or any window. The effect grabs the mouse, so that the clicks do not get to the windows. > > The compiz plugin I mentioned above lets you interact with the desktop, too. > Maybe it's also some kind of minimizing hack... It probably is, although I have not looked at the code
@Benno: do you request a) a way to just minimize all windows (that is showing a new one won't change their minimized state) b) a fancy effect to slide around windows c) both a) needs to be some sort of plasimoid (while some dbus interface asde cascadeDesktop probably won't hurt kwin either ;-) you might be pretty lucky on b) http://www.kde-look.org/content/show.php/BeDropped+%3B-%29?content=120847 while it does not keep minimized windows partially visible, and to not raise wrong assumptions, i wrote that long before this report :-P
After reading through the feature request again I just don't see any advantage over the existing functionality like show desktop or dashboard. So sorry I don't think it makes sense to add more functionality. Nevertheless I want to thank you for the feature suggestion.