https://bugs.kde.org/show_bug.cgi?id=454950
--- Comment #7 from doncb...@gmail.com --- 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. -- You are receiving this mail because: You are watching all bug changes.
