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.
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.
> 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).
> 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.
> 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.
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.
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.
A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-desktop/-/merge_requests/2722
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
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.