Bug 454950 - Floating panel should remain floating in "Auto-hide", "Windows Can cover," and "Windows go Below" modes
Summary: Floating panel should remain floating in "Auto-hide", "Windows Can cover," an...
Status: RESOLVED FIXED
Alias: None
Product: plasmashell
Classification: Plasma
Component: Panel (show other bugs)
Version: 5.24.90
Platform: Neon Linux
: NOR wishlist
Target Milestone: 1.0
Assignee: Plasma Bugs List
URL:
Keywords:
: 462538 (view as bug list)
Depends on:
Blocks:
 
Reported: 2022-06-07 02:34 UTC by doncbugs
Modified: 2022-12-02 11:11 UTC (History)
4 users (show)

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


Attachments
support for this: a floating panel under a transient Visibility (148.52 KB, image/png)
2022-06-09 23:27 UTC, doncbugs
Details

Note You need to log in before you can comment on or make changes to this bug.
Description doncbugs 2022-06-07 02:34:55 UTC
SUMMARY
As of 5.24.90, the Plasma panel can now float. Unfortunately, it seems to only float on a near empty desktop. Relevant options like Windows Can Cover or Windows Go Below, or perhaps even Auto Hide do not change the behavior and the panel simply acts like a thicker version of the regular panel.


STEPS TO REPRODUCE
1. Set panel to Floating
2. Set it to any of the 3 options: Windows Can Cover, Windows Go Below, or Auto Hide
3. Maximize any window or move it such that it falls under the panel

OBSERVED RESULT
The panel fills in the space and basically behaves like the current panel

EXPECTED RESULT
The panel floats, only properly docking itself for the Always Visible state to minimize distraction. Otherwise, an auto-hidden panel should float, appearing and disappearing when requested, as the content behind it is window content. Likewise, Windows Can Cover, and Windows Go Below also ensure that window content is the only background of the panel.

SOFTWARE/OS VERSIONS
Operating System: KDE neon Testing Edition
KDE Plasma Version: 5.24.90
KDE Frameworks Version: 5.95.0
Qt Version: 5.15.4
Kernel Version: 5.13.0-44-generic (64-bit)
Graphics Platform: X11

ADDITIONAL INFORMATION
Why Niccolo, why
Comment 1 Nate Graham 2022-06-07 17:43:56 UTC
I can reproduce this only when there are any Maximized windows, which is the expected behavior. Does that match what you're seeing, or does this also happen when no windows are maximized?
Comment 2 doncbugs 2022-06-09 02:25:05 UTC
This is really more of a wishlist. I realized that the "floating panel" part is only available on an empty desktop or with all windows moved up and away from the panel. I was just humored by the idea that I would basically never see the floating panel and in effectively every one of my use cases, it's just the same Plasma panel but with more padding.

As it stands, I think the panel's behavior is a bit strange and am not sure how reverting to the regular Plasma panel when a user maximizes a window is beneficial. I think Niccolo may have mentioned a technical reason for why it didn't work out.
Comment 3 Nate Graham 2022-06-09 03:14:16 UTC
It should float anytime there are no maximized windows. Are you saying that you almost always have at least one maximized window?
Comment 4 doncbugs 2022-06-09 23:20:50 UTC
My bad, I see my communication error.

Yes, I do very frequently have a maximized window, however, I am not saying I disagree with the decision to make the panel stop floating when a window is maximized (when Visibility is set to Always Visible).

In the context of the floating panel as it stands, I'm approaching this change as KDE incrementally gaining the functionality to imitate docks like those present in macOS, elementary, and gnome.

My original thought was that under the KDE default panel configuration, with floating applied, the panel filled in the gaps that would show the background to seamlessly meet with the window. It was sort of a distraction minimizing behavior, like the Adaptive setting.

However, this logic breaks down for transient panel states like Windows Go Above, Windows Go Below, and Auto Hide, since they do not reserve any space and only can show over the window content, preventing the background from ever being seen if windows are tiled side-by-side or maximized.

Thus, I assumed that when a transient state was set, the panel would behave like the other docks and retain its rounded corners , even if there was content behind it, because that content was just the window that the user was focusing on.



In summary, I felt that the panel should remain in its floating state continuously if a transient Visibility was set. If a permanent Visibility was set, and the wallpaper could be seen, it should fill in the gap to seamlessly meet with the window content, concealing the wallpaper and minimizing distraction.
Comment 5 doncbugs 2022-06-09 23:27:00 UTC
Created attachment 149584 [details]
support for this: a floating panel under a transient Visibility

The uploaded image was done by using an auto-hiding panel and resizing a window to look maximized. Of course, pressing the maximize button immediately causes the panel to attach to the bottom of the screen. This is essentially what I think should be a supported use case.
Comment 6 Nate Graham 2022-06-10 16:23:08 UTC
Got it. So you want a floating panel to remain floating in when set to "Auto-hide", "Windows Can cover," and "Windows go Below" modes? Seems reasonable.
Comment 7 doncbugs 2022-06-11 01:59:02 UTC
Yes, I believe that use case is what many users will enjoy and intend to use the panel for. Well, for the ones that would enable floating.

I'm not suggesting the following should be implemented soon, nor am I sure if it should be at all, but I think it is worth at least mentioning once.

So since we're on the topic, I do want to mention that I suspect there is an interaction with whether the panel is maximized under Always Visible.

I think the traditionally expected behavior of an (unmaximized?) panel (on the bottom of the screen) is to close the space between the bottom of the screen and a tiled window/maximized window. Otherwise, float with the usual margin(s) between the panel and the (bottom) of the screen.

I understand this might flip half of the new panel code, but it could resolve the padding problem (for the probably less than common case of a non-maximized panel). Obviously, the maximized panel remains the same and probably has no distinct other way of being implemented other than the current one. But for an unmaximized panel gliding from floating to the bottom and meeting with the screen (but retaining corners), whilst snapping windows to the top of the panel (as though the panel were of its padding-less floating height), it seems beneficial. But now the code for it seems to have a lot of arbitrary and unpredictable behaviors.

Niccolo may have discussed the above in one of his panel videos, but I can't remember, so my apologies if it seemed to be technically impossible.
Comment 8 Niccolò Venerandi 2022-06-15 18:11:15 UTC
Sounds reasonable to me too, and should be an easy fix. Added to my to do list
Comment 9 Bug Janitor Service 2022-09-20 18:53:29 UTC
A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-desktop/-/merge_requests/1163
Comment 10 Nate Graham 2022-09-21 14:40:21 UTC
Git commit 0eed74a6fe55fbb7c3e0f1a5b3fb9d548ac7e8de by Nate Graham, on behalf of Niccolò Venerandi.
Committed on 21/09/2022 at 14:34.
Pushed by ngraham into branch 'master'.

Only de-float the panel if it is set in normal mode

M  +1    -1    desktoppackage/contents/views/Panel.qml

https://invent.kde.org/plasma/plasma-desktop/commit/0eed74a6fe55fbb7c3e0f1a5b3fb9d548ac7e8de
Comment 11 veggero 2022-12-02 11:11:26 UTC
*** Bug 462538 has been marked as a duplicate of this bug. ***