Created attachment 149736 [details]
Floating panel without maximized windows.

Created attachment 149737 [details]
Floating panel with maximized window.

Going back to a normal state would require dynamically change the size of the panel window every time a window is maximized. If I recall correctly, this wasn't quite feasible...

(In reply to Niccolò Venerandi from comment #3)
> Going back to a normal state would require dynamically change the size of
> the panel window every time a window is maximized. If I recall correctly,
> this wasn't quite feasible...

It is still an unexpected behavior and it does not respect the height of the panel. In counterpart Latte also has the option of having a floating panel and maintains the desired size.
I think the initiative is great, but it is something that should be corrected.

As an alternative, the panel should still have the space, without increasing its size. It's not perfect, but it's better than what we currently have.

Yes, we've gotten other comments saying that it should just not de-float at all when there are maximized windows. See Bug 454950.

(In reply to Nate Graham from comment #6)
> Yes, we've gotten other comments saying that it should just not de-float at
> all when there are maximized windows. See Bug 454950.

The difference is that there it asks to make it similar to a dock, when I am reporting that it does not respect the height of the panel when maximizing a window. Similar but not the same. I gave the second option of leaving it floating because of the comment that it would be impossible to maintain the size.

I will investigate whether this can be addressed by a more natural de-float or not as soon as I have more time; I'll admit I don't remember exactly why I hadn't implemented it, but I recall I attempted and had a good reason not to.

Making the panel not de-float at all is of course an option, though not one that I'd be a great fan of.

(In reply to Niccolò Venerandi from comment #8)
> I will investigate whether this can be addressed by a more natural de-float
> or not as soon as I have more time; I'll admit I don't remember exactly why
> I hadn't implemented it, but I recall I attempted and had a good reason not
> to.
> 
> Making the panel not de-float at all is of course an option, though not one
> that I'd be a great fan of.

Bug 454950 suggests floating when certain options are enabled, so you can use it as a dock. It is an interesting option, but I consider that fixing the current problem is more important.

(In reply to Niccolò Venerandi from comment #3)
> Going back to a normal state would require dynamically change the size of
> the panel window every time a window is maximized. If I recall correctly,
> this wasn't quite feasible...

Maybe the panel could move downwards and at the same time add padding to the left and right sides. That way panel is the same height and size.

A possibly relevant merge request was started @ https://invent.kde.org/plasma/plasma-desktop/-/merge_requests/1206

Git commit ed0214057e7ae78bedc4486a6344db9459ce5570 by Nate Graham, on behalf of Niccolò Venerandi.
Committed on 25/10/2022 at 14:52.
Pushed by ngraham into branch 'master'.

Panel: when floating, de-float when window touches it

A floating Panel now de-floats and becomes opaque whenever a window touches it.
This also allows for a thinner Panel when a window is maximized (a normal Panel
is 44 px; before this patch a de-floated one was 60, now it's 52px) and that should
allay complaints about excessive margins).
Related: bug 455538, bug 455483
FIXED-IN: 5.27

M  +29   -6    desktoppackage/contents/views/Panel.qml

https://invent.kde.org/plasma/plasma-desktop/commit/ed0214057e7ae78bedc4486a6344db9459ce5570

(In reply to Nate Graham from comment #12)
> Git commit ed0214057e7ae78bedc4486a6344db9459ce5570 by Nate Graham, on
> behalf of Niccolò Venerandi.
> Committed on 25/10/2022 at 14:52.
> Pushed by ngraham into branch 'master'.
> 
> Panel: when floating, de-float when window touches it
> 
> A floating Panel now de-floats and becomes opaque whenever a window touches
> it.
> This also allows for a thinner Panel when a window is maximized (a normal
> Panel
> is 44 px; before this patch a de-floated one was 60, now it's 52px) and that
> should
> allay complaints about excessive margins).
> Related: bug 455538, bug 455483
> FIXED-IN: 5.27
> 
> M  +29   -6    desktoppackage/contents/views/Panel.qml
> 
> https://invent.kde.org/plasma/plasma-desktop/commit/
> ed0214057e7ae78bedc4486a6344db9459ce5570

I don't see how that solves it when it has only removed 8px of the 16px that the fix itself says it had. It's an improvement, sure, but I don't see how it's a solution to the bug. 1+1=3 is a better answer than 5, but it's still not the answer.

According to Niccolò, this is the best we can do for now; removing the margins completely is extremely technically challenging and might not work.

The current state with that commit applied brings us back to the margins that the Task Manager used for years and years, before we got rid of them. So it's no worse than that, at least. Let's be happy with this for now, and hope Niccolò finds a way to remove the margins completely. :)

(In reply to Nate Graham from comment #14)
> According to Niccolò, this is the best we can do for now; removing the
> margins completely is extremely technically challenging and might not work.
> 
> The current state with that commit applied brings us back to the margins
> that the Task Manager used for years and years, before we got rid of them.
> So it's no worse than that, at least. Let's be happy with this for now, and
> hope Niccolò finds a way to remove the margins completely. :)

I get that, but why tag it as fixed when it hasn't really been fixed yet? It does not seem right.
The bug report is very clear, the panel does not respect the selected size, and reducing only 8 px is not enough to "shut us up". As hard as it is to fix, the current implementation makes it unusable for me and I don't accept being labeled as fixed when it clearly isn't.

Sometimes life is messy. I guess I can mark it as RESOLVED INTENTIONAL to reflect that an ideal fix isn't possible right now, if it will make you feel better.

Created attachment 153207 [details]
de-floating broken for top panel

Now de-floating is broken for top panels. With the recent fix applied, I get gaps on the top, left and right when a window is maximized.

The panel also does not become opaque.

Looks fine now, probably I didn't have the recent enough build of plasma-workspace that had the other needed commit. Sorry for the noise!

So with Plasma 6.0 the situation has been further improved, now the de-floated panel is the same height as it would be if floating isn't enabled at all. The panel does still add extra margins on the side, so while the issue stated in the title isn't resolved the main problem as per the description and comments (the height) is actually fixed, plus unlike the height the extra side margins don't take away space from apps anyway.

I do still think that it would be great if the side margins could also be removed when de-floating, but that's certainly more of a "wishlist" thing than the height problem, so thanks for the great work!