Bug 498035 - Difference between "Always visible" and "Windows go below" visibility modes is not clear from the labels alone
Summary: Difference between "Always visible" and "Windows go below" visibility modes i...
Status: RESOLVED FIXED
Alias: None
Product: plasmashell
Classification: Plasma
Component: Panel (show other bugs)
Version: 6.2.4
Platform: Debian unstable Linux
: NOR minor
Target Milestone: 1.0
Assignee: Plasma Bugs List
URL:
Keywords: usability
Depends on:
Blocks:
 
Reported: 2024-12-29 18:28 UTC by Oswald Buddenhagen
Modified: 2025-01-24 05:36 UTC (History)
5 users (show)

See Also:
Latest Commit:
Version Fixed In: 6.4.0
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Oswald Buddenhagen 2024-12-29 18:28:07 UTC
it's not clear to me what the difference between the "always visible" and "windows go below" panel visibility modes is - the descriptions seem to be kind of synonymous, and superficially they appear to do the same thing.

don't tell me to rtfm; it's already an UX fail that i have to ask the question. (also, F1 doesn't work there, and i fail to find tfm quickly).

based on some random hits, i guess "always visible" is meant to be "block windows" (as opposed to "dodge windows"), so kind of "pretend to be the screen edge" - but that's pointless at least with my kwin config, as windows can be freely placed such that parts are off-screen.
Comment 1 Filip 2025-01-03 10:05:42 UTC
They don't do the same thing

always visible: You're right, panel acts kinda like the edge of the screen. So when you maximize the window, bottom edge of the window starts from top of the panel. Also panel de-floats when a window is touching the panel. And of course you can drag your window over that panel. You don't lose any window content in this case.

windows go below: Window takes the whole screen and it looks like the panel is drawn on top of the window. Panel in this case hides a part of the window content. You can best see this when you select the floating panel.

I'll close this now as it is not a bug.
Comment 2 Oswald Buddenhagen 2025-01-03 12:41:55 UTC
> Also panel de-floats when a window is touching the panel.

uh, yeah, it does (which i didn't notice, because i disabled the floating as the first thing). what is the justification for such plainly weird behavior?

> And of course you can drag your window over that panel. You don't lose any window content in this case.

no, i can't. that would be "windows can cover" mode, which was intentionally removed with a rather poor justification.
in fact, it behaves like "windows go below", which is the central point of this report.

maybe you should rename the mode, for example "make windows dodge" to contrast it with "dodge windows". i think i've seen it named "exclude windows" somewhere, but that's an equally bad name, as it can be understood only once one already knows what it does.

but even then it's still not clear why dragged windows don't actually respect the border and just slide under the panel. i thought that this might be the effect of a kwin setting, but that doesn't appear to be the case.

so at the very least the combos should have tooltips which explain the full set of behaviors and what external influences exist.

and why does "windows go below" also apply to maximization? there is no sensible use case for such behavior (as opposed to manually sliding part of the window below the panel). either the panel or the window should dodge (probably the latter).
Comment 3 Kai Uwe Broulik 2025-01-03 13:18:39 UTC
> and why does "windows go below" also apply to maximization? there is no sensible use case for such behavior

Clearly there is a use case or else this option wouldn’t exist. I have seen people just have a small clock in the corner of the screen that wouldn’t impact window placement.
Comment 4 Oswald Buddenhagen 2025-01-03 13:31:19 UTC
> Clearly there is a use case or else this option wouldn’t exist.

i didn't question the option, but a particular aspect of it. and that could have been just coincidental, or "just because" - happens often enough.

> I have seen people just have a small clock in the corner of the screen that wouldn’t impact window placement.

hmm, indeed, i was thinking of full-size panels only.

though "always on top" would be probably a better name, also because that's the terminology used by window managers.
Comment 5 Nate Graham 2025-01-04 05:17:11 UTC
Basically "pretend to be the screen edge", yeah. It affects where maximized and tiled windows will stop maximizing and tiling to.

The strings are not 100% clear right now, but I think for the average user, it should be pretty obvious. Suggestions that don't make it worse are welcome.
Comment 6 Niccolò Venerandi 2025-01-08 20:24:17 UTC
I think the label is okay, but we should introduce again the correct visual representation for this feature. Currently it has the same one as auto-hide, which is wrong.
Comment 7 Bug Janitor Service 2025-01-15 10:27:31 UTC
A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-desktop/-/merge_requests/2722
Comment 8 Niccolò Venerandi 2025-01-21 18:02:30 UTC
Git commit 5218198890ea88f3e0cbc5fc64cf9c7ed99a3b6a by Niccolò Venerandi.
Committed on 21/01/2025 at 16:13.
Pushed by niccolove into branch 'master'.

Introduce animations for all Visibility panel options

M  +13   -1    desktoppackage/contents/configuration/PanelConfiguration.qml
M  +140  -9    desktoppackage/contents/configuration/panelconfiguration/PanelRepresentation.qml

https://invent.kde.org/plasma/plasma-desktop/-/commit/5218198890ea88f3e0cbc5fc64cf9c7ed99a3b6a
Comment 9 Oswald Buddenhagen 2025-01-21 19:39:31 UTC
i don't think that some tiny animations will adequately confer the subtleties of the different modes, if only because the effects are different between manual resizing and maximization.
but then, i don't even know what animations you're talking about. "all" in the commit message suggests that "some" were already present, but i didn't notice anything like that.