[show desktop]: hides panel also

[star-buck]

When pressing the "Show Desktop" widget. all windows but also panel is hidden...

[davidedmundson]

Upstream bug report: https://bugs.kde.org/show_bug.cgi?id=346837

[star-buck]

Why this?: https://bugs.kde.org/show_bug.cgi?id=346837#c16

[star-buck]

So is there any "proper" solution/workaround to have the expected behaviour back? That is: "Show Desktop" = minimize/hide/move windows, but leave taskbar etc. (like it does under any other DE)?

[davidedmundson]

I assumed someone was going to fix it for 5.3.1

[star-buck]

any fix for right now? i plan to get n16 out before the meeting in 2 weeks...

[mgraesslin]

The change is actually intended behavior. The feature is called "show desktop" and the panel is not part of the desktop window. The question we looked at is "why should the panel be there?" It's always visible, so if one wants to "show the desktop" the panel should also be hidden as it's also distracting from showing the desktop.

But we are open to change that again. But we want to know/understand why the panel should be visible in the show desktop feature. We want to understand the use case.

[star-buck]

Just one question: Is there still a "minimize all windows" function or not? The "minimize with panel" visible had many usecases, where the now "show desktop without panel" i fail to see even one usecase where the panel hidden also is relevant...

[mgraesslin]

Is there still a "minimize all windows" function or not?

yes there is: we introduced the functionality as a kwin script, which needs to be enabled.

[star-buck]

So now people who like to restore their usecases are left with a Kwin script...

That begs some questions:

• Why was a well known and uniformly implemented use case (also across all other DEs) changed, when plasma5's goal is to preserve any functionality and introduce new changes very carefully, that is via alternatives et al?
• What sense makes it to show the desktop without the panel, is there anything helpful expected to see underneath it?

[mgraesslin]

That's not really the case. Minimize all windows was a very hidden feature not exposed at all in the config.

The change was motivated by the problems our users had with the implementation of show desktop. Users were heavily confusing a "minimize all windows" and "show desktop". No matter how it worked, we had users not happy with the behavior, especially those who thought that "show desktop" is minimize all. So to say we addressed exactly your question number 1 slightly rephrased: "why is this feature broken, while it works on all other desktops?"

So what we did is introduce two dedicated features;

• show desktop
• minimize all

The latter we moved from being a hidden config option to being a shown option as a default shipped script. This is a major improvement for those wanting that feature. Show desktop in result is moved into an implementation which does what it's called and how it is described in the standard and especially we morphed the state with the dashboard (which was severely broken in 5.x).

The change was discussed by a rather large group of developers, members of VDG, etc.

[star-buck]

Minimize or hide Windows is a technical "play of words": "Show desktop" arguably for a majority of users (and across all desktops) means this: Minimize (or otherwise hide) all open windows while having the panel(s) still visible. Swapping that around with something else from 5.2 to 5.3 that "freezes" the desktop just to look at, but not interact anymore is confusing and a real step backwards on usability imo...

[mgraesslin]

this is not what we experienced from what we saw in the majority of bug reports. To me it looks like you belong to those users who thought the feature is "minimize all windows", which it never was and for which this feature was strongly broken. For the users with this assumption the implementation just never worked and there was a hidden hack to make it work better. We moved this functionality into a script and streamlined the implementation.

[star-buck]

"Show desktop" for an absolute majority of users (and across all desktops) means this: Minimize (or otherwise hide) all open windows while having the panel(s) still visible. Why even argue that point? Windows has exactly this implemented, as has OSX, Gnome2, Mate, Cinnamon, etc. eg xfce: http://docs.xfce.org/xfce/xfce4-panel/showdesktop

[star-buck]

Sorry for being a bit harsh on this, but even if we decide to do some change like that and we get direct feedback from our userbase, we need to challenge ourselves and our way of thinking and not have the users explain why they love to use KDE because of its features. This is the point where we need to step back and question the mentality this case shows (again) how we as developers presenting this to our users (most of which, similar like in a restaurant being served bad food, wont even bother to report back and just look for something else):

"write your own script", write a patch, or even "use this script as workaround" is nothing that has to do with professionalism, read here:

"If KDE wants to evolve, wants to stay relevant, wants to compete, not just with other free software projects that provide equivalents to what KDE offers, that mentality needs to go. Either we're writing software for the fun of it, or we're writing software that we want people to choose to use (and I've got another post coming up elaborating on that distinction)."

[notmart]

hmm, what about keeping the panel when triggered from a panel applet (in this case the rationale would be keeping visible the button that undoes the effect) and not when triggered as dashboard?

[star-buck]

@notmart : Thats a good point, so what about the usecase for it to be triggered from a hotcorner?

[mgraesslin]

@star-buck please see that we put a lot of thought into changing it. We don't change because we want to annoy users. We have seen that the feature had been broken for our users for years. We regularly got bug reports about this and the way how users interact with it and how it breaks for them.

The problem with the panel had been in the past that users interact with the panel and that sets back the state to pre show desktop. Which is again what users didn't anticipate and which gives them windows in a non-expected state. Show desktop does not minimize windows, but users think so. Now they click a window in the panel and the window does not unminimize but the opposite.

Additionally there's the problem that there are 3rd-party windows using type panel and users expect them to go away - e.g. to get to the Plasmoid behind those "fake panels".

@notmart what you suggest needs a completely new protocol on X11 level. Show desktop wouldn't be that, we would need a new call which needs to be handled.

[notmart]

personally I wouldn't mind to have the panel always visible, since the desktop containment forbids to put applets under the areas taken by the panel anyways. I do remember users asking for the panel to be hidden back when it wasn't. Martin, do you know an use case they cited in particular? (or potential problems that would occur in having the taskbar reachable when the effect is on)

[mgraesslin]

Let me quote the standard we implement: http://standards.freedesktop.org/wm-spec/wm-spec-latest.html#idm140200472673088

Some Window Managers have a "showing the desktop" mode in which windows are hidden, and the desktop background is displayed and focused. If a Window Manager supports the _NET_SHOWING_DESKTOP hint, it MUST set it to a value of 1 when the Window Manager is in "showing the desktop" mode, and a value of zero if the Window Manager is not in this mode.

[star-buck]

We certainly need to argue how everyone else understands "Show Desktop" even if some tech spec calls it differently... Changing the perceived meaning by implementing a different behaviour (including but not limited to hiding the panel) is confusing for people...

[notmart]

right, sent my reply a second after martin's one that would have ansered: so yeah, actually minimizing windows was indeed very broken (setting the state, unrelated on how it gets presented) and yeah, having the taskbar reachable would cause some interaction problem. unless.. either the taskbar knows that this effect is triggered and just untriggers it upon clicking of any entry. or when a window gets activated, the effect gets "unapplied" from the window?

[mgraesslin]

@star-buck and that's exactly what we addressed. The PRECEIVED meaning was broken and we fixed it. And please note that what we saw from the bug reports is that "show desktop" == "minimize all" is not what all users expect. I do understand that you are concerned about the users who expect it to work in that way, but it doesn't change one important fact: there are two different use cases and behaviors which cannot be served one way only.

If we need to improve the "minimize all windows" use case, that's fine. We can do it. But not by breaking the "show desktop" use case.

[mgraesslin]

or when a window gets activated, the effect gets "unapplied" from the window?

that's part of the problem we saw. The mode ends, restoring all windows, which is not what users expect from a "minimize all windows".

[mgraesslin]

For more information especially about the discussion regarding panels please see https://git.reviewboard.kde.org/r/122679/

[star-buck]

Again, the main error lies in redefing "Show Desktop" contrary to what is commonly understood by anyone else for that term: "Show Desktop" for most users is "minimize all windows" while leaving the panel intact:

http://docs.xfce.org/xfce/xfce4-panel/showdesktop http://windows.microsoft.com/en-us/windows/minimize-open-windows-view-desktop#1TC=windows-7 https://www.youtube.com/watch?v=WbgRLeMH6QM

[mgraesslin]

Plasma is neither XFCE nor Microsoft Windows. In Plasma "show desktop" has never been "minimize all windows" - I can show you the code dating back to KDE 2 :-) And as I have already said: our bug reports did not indicate that the majority of users think it's "minimize all windows", but rather that there are two different feature sets.

Anyway: I do not want to discuss this to end as we are moving in circles. In the end I don't care about it. It's a feature I don't use (because it used to be broken for years) and nothing I want to get upset about. The feedback I can give from maintaining KWin for several years is that there is a need for two different features: "show desktop" and "minimize all". If the latter feature is not sufficiently implemented, it can be improved. We then have to put some thought into it, to equally well present both features.

[star-buck]

There are valid reasons NOT to redefine "Show desktop" to something else with hiding panels etc.:

Simply using "show desktop" icon, hotcorner method etc. for something DIFFERENT, we effectively leave all users of the MAIN, well understood and expected usecase to "minimize with panels" empty handed.

Even if that mode of minimizing = "Show desktop" needs improvement, a reassociation creates two pitfalls: first having something new associated with something that simply is an established term and second: having no replacements in place at all.

The reasonable way would be to keep using an improved version of minimze as "Show desktop" (aka minimize+panels visible) and leave it to those wanting a new mode with "hiding panels", etc. that this also then needs additional effort of creating a new icon under "add widgets", hotcorner associations, etc.

• right now, any Plasma user will continue to try and use "Show desktop" as expected, so with any panel to be visible
• when they see panels are disappearing they think its a bug
• then they are told: Well, its expected now that way, and you were wrong to use "Show Desktop" for minimize+panel the whole time!
• and then they find out there are no implemenations at all such as no icon for panel under "add widgets", no hotcorner mode association, etc....

what about professionalism? http://www.valdyas.org/fading/index.cgi/2015/04/21#evolve

[sebasje]

I've taken care of the replacement bit, a Plasmoid that gives the minimize windows while keeping the panel. It's master material (new plugin, new translations, new code), but perhaps it can be added as a patch to Netrunner's packages, to cover at least that case.

https://git.reviewboard.kde.org/r/123653/

[sebasje]

Here's a patch that reverts Kwin 5.3.0 to the old behaviour. We're seeking to restore the old behaviour upstream for 5.3.1, so this patch can probably be dropped then.

https://git.reviewboard.kde.org/r/123686/diff/raw/

Please integrate into the kwin package for Netrunner 16.

[star-buck]

Thanks! Before we apply it: This also works with the "Show Desktop" trigger set as hotcorner?

[star-buck]

@sebasje : Do you know if this patch will work for "Show Desktop" as hotcorner?

[sebasje]

Yes hotcorner is among the scenarios I've tested.

[star-buck]

@apachelogger : lets package patches in netrunner-16-ci-updates for now.

[hsitter]

https://launchpad.net/~netrunner-os/+archive/ubuntu/netrunner-16-ci-updates/+sourcepub/5054549/+listing-archive-extra https://launchpad.net/~netrunner-os/+archive/ubuntu/netrunner-16-ci-updates/+sourcepub/5054550/+listing-archive-extra

[star-buck]

fix seems to restore functionality for now.