Created attachment 172188 [details] Example SUMMARY When arranging windows (moving window with the Shift key) in the configured tiling arrangement (the one that we configure with Meta+T), when the padding is 16px or less, this makes the panel de float. When we set to 17px or higher, we have the expected behavior (the panel remains floating, since there is nothing touching the panel). STEPS TO REPRODUCE 1. Change the panel to float mode 2. Open the Tiling Editor (Win+T) and change the padding to 16px or lower 3. Move windows with Shift pressed and you will see that the panel de-float 4. Open the Tiling Editor (Win+T) and change the padding to 17px or higher 5. Move windows with Shift pressed and you will see that the panel remains floating, as expected OBSERVED RESULT When moving window in a Tiling Editor arrangement with padding 16px or less, the panel de-float. When moving with padding 17px or higher, it remains floating. EXPECTED RESULT The panel should remains floating even if we selected lower values as padding, like 8px or 16px. SOFTWARE/OS VERSIONS Operating System: openSUSE Tumbleweed 20240726 KDE Plasma Version: 6.1.3 KDE Frameworks Version: 6.4.0 Qt Version: 6.7.2 ADDITIONAL INFORMATION Kernel Version: 6.9.9-1-default (64-bit) Graphics Platform: Wayland Processors: 16 × AMD Ryzen 7 4800H with Radeon Graphics Memory: 30,7 GiB of RAM Graphics Processor: AMD Radeon Graphics Manufacturer: Acer Product Name: Nitro AN515-44 System Version: V1.04
Can reproduce with current git master. I guess the padding should take into account any padding already added by a floating panel.
This bug still happens. I think the tiling manager should be aware of the panel "style". Looks like now all the calculations are done based on the "non-floating" state of the panel. If the user uses the panel floating, the calculations of the bottom padding should be done with the padding of the floating panel (8px) in mind.