Hi everyone, I must admit that I totally underestimated the complexity of this whole issue. It's so crazy, just reading this thread made my head spin.
This situation is also an excellent example of where design "in a vacuum" (i.e. without any user research) shows its limits. Apparently, different users use Show Desktop and/or Dashboard in very different ways and for very different purposes. Without having any information about which types of (and how many) users use it in which way, we're jumping from bug report to bug report, trying to satisfy everyone, which is simply not possible. I've read the whole thread, but I decided to not quote any of the other emails for the sake of readability. I agree that hiding the panel in this mode seems to have introduced more problems than it solved, so I agree that this should be changed back. However, what we have to avoid at all cost is the situation where users click on a task in the taskbar but the window stays invisible (hiding the panel avoided this, but, in retrospect, at a too high cost). Therefore, two possible things that could happen is that either only this specific window is shown, or the mode is broken and all previously shown windows return. Both variants have their set of advantages and disadvantages, and regardless of what we choose, we'll get bug reports from users to whose typical use of the feature this behavior does not fit. That seems unavoidable. If it does minimize all windows, then it should really do that, just as if one would manually click "Minimize" on every single window. That also means that they the windows could not be all brought back at once, but only one by one. Anything else has a high potential of leading to a not clearly defined state (e.g. what happens if I minimize all, then click a window in the taskbar, minimize that again, and then "un-minimize"). That would probably introduce the fewest problems, but would also be hardly useful for just quickly interacting with the desktop and then continuing work as before. Un-hiding all windows as soon as the user clicks on a task in the taskbar or starts a new application would satisfy the "quick peek" usecase best, but would also mean that users could not use this effect as a means to "clean up their workspace". I do agree with Thomas, however, that this is not what "Show Desktop" is meant for anyway, and virtual desktops are indeed the better means for this. Having a separate Plasmoid plus keyboard shortcut to do an actual "minimize all" for cleaning up the workspace without switching to a different VD (as sebas proposed if I understood correctly) as an alternative for those who want that does sound like a great idea to me. So, to summarize, from my perspective, the way to enrage as few users as possible would be to - Make Show Desktop hide all windows but break whenever a window that doesn't directly belong to the shell or a Plasmoid is created/manually shown, and keep the panel visible - Provide an additional shortcut plus Plasmoid to minimize all windows, which really does that (no special stuff here). When in doubt, we should prefer clearly defined behavior (even if some users don't like that behavior) to unpredictable behavior that may leave users confused. If someone writes a bug report because he or she simply does not like a behavior, we can always say "Well, but that is how it was intended, sorry, deal with it". If a user files a bug because they don't understand what their system is doing anymore, it is a valid usability bug. That is my position. I have no idea about any technical problems any of this may introduce, so of course you guys have the final word on it. If you decide the safer way is to roll back to whichever working state until we've ironed out issues with the new behavior, then I won't protest. While the situation up until 5.2 definitely was not perfect, it's better than a broken state. If fixing any actual bugs in the 5.3 implementation and not hiding the panel is the preferred solution form a technical perspective as well, all the better. I hope I haven't confused everyone more than we already are. Best, Thomas _______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
