Made auto-hiding on overlapping work under kwin_wayland

[tsujan]

First, the method LXQtWMBackend_KWinWayland::isAreaOverlapped() needed enhancements.

Second, QVariantAnimation is used to set appropriate negative margins and have animation with auto-hiding. The animation is exactly like in X11.

NOTE: I'm not sure that negative margins work under other Wayland compositors, but for now, auto-hiding on overlapping can't work with them. KWin wins again ;)

Closes https://github.com/lxqt/lxqt-panel/issues/2113

[tsujan]

@stefonarch I have it under kwin_wayland, and it works fine. Please test it under other compositors, but note that auto-hiding on overlapping can't work with them, because overlapping is only detected by the kwin_wayland backend; just test if the animation works.

[tsujan]

Oh, I forgot to say that I tested it only for the bottom panel ;)

[marcusbritanicus]

I'm not sure that negative margins work under other Wayland compositors

It works on sway and wayfire - I have tested it on wayfire, few others have reported that negative margins work on sway.

auto-hiding on overlapping can't work with them. KWin wins again

Indeed. KWin will be the only compositor that supports this feature, and that status is unlikely to change for quite a while.

[tsujan]

It works on sway and wayfire

Very good! Thanks for the info! I think it should work with labwc too.

... and that status is unlikely to change for quite a while.

Auto-hiding on overlapping is a nice feature, but its lack isn't a disaster ;)

KWin already had several advantages; now this one is added to them.

[tsujan]

@marcusbritanicus Wow, you may not believe me, but I hadn't seen your comment at https://github.com/lxqt/lxqt-panel/issues/2113#issuecomment-2458849007 — I saw only the comment below it. Very interesting that we came to the same conclusion.

[stefonarch]

Animation works fine on every compositor I've tested (niri, river, labwc,Hyprland) and overlapping works fine on KWin. It appears also with Meta shortcut (Hyprland):

https://github.com/user-attachments/assets/acb7fde8-4b77-41cb-be74-29f05675af8f

What doesn't make sense is the option "reserve space" as it doesn't, not even on Kwin, and disabling the "overlapping" option if not on Kwin or X11 would be fine.

[marcusbritanicus]

@marcusbritanicus Wow, you may not believe me, but I hadn't seen your comment at #2113 (comment) — I saw only the comment below it. Very interesting that we came to the same conclusion.

@tsujan Great minds think alike :wink:

[tsujan]

What doesn't make sense is the option "reserve space"

Good observation! It's intentional.

I have no idea why it was used with an auto-hiding panel in X11 — perhaps because X11 could be without a compositor — but it didn't work with a negative layer margin on Wayland; instead, it made windows move by a few pixels on showing/hiding the panel. So, I removed it from Wayland. See the code comment that says, "// NOTE: For some reason,..."

Another thing that you may have observed is that the "hidden" panel is visible like a very thin rectangle. That's because Qt can't set the window opacity under Wayland.

[tsujan]

Merging for more tests by git users?

[stefonarch]

So "reserve space" should be deactivated if "autohide" is set.

[tsujan]

So "reserve space" should be deactivated if "autohide" is set.

It reserves 4 pixels in X11. Why we have it for an auto-hiding panel, I don't know. IMO, it's better to remove it — I mean, to disable it with auto-hiding panels. But it needs to be discussed, and if all agree, it should be removed in another PR.

and disabling the "overlapping" option if not on Kwin or X11 would be fine.

We don't know what will happen. But I agree with @marcusbritanicus that it won't happen soon in any other compositor. Again, we need to discuss it, and it needs another PR.

[stefonarch]

"reserving space"=number of pixel of panel height, and that is not reserved when the panel is shown, so it should be greyed out. It works as exclusive zone if no autohide is used.

[tsujan]

"reserving space"=number of pixel of panel height

It's 4 px with auto-hiding, whether the panel is shown or not, in X11 too.

No graying out of anything in this PR ;)

[tsujan]

If something is going to be disabled in another PR, it's this: the reserve box if auto-hiding is checked and only on Wayland.

Overlapping shouldn't be disabled based on the compositor. We already have an ugly instance of compositor check, which was inevitable; adding another instance would start a mess in the code. At most, a tooltip could be added in another PR.

[tsujan]

Now the setting about margin visibility works too, and a case specific to Wayland is taken into account.

[stefonarch]

Now the setting about margin visibility works too

Confirming. Although it looks like all default panels are half translucent on every compositor on Wayland if no background color is set - so the margin is hardly visible with default settings.

[tsujan]

Let's first decide https://github.com/lxqt/lxqt-panel/pull/2166 because, if approved, it might need a point release.

[tsujan]

The only "issue" is that KWin's blur effect (applied by Kvanum) isn't updated for the tiny margin of a hidden panel. But it's a small bug in KWin and not a big deal; 99% of users don't see it either.

[marcusbritanicus]

That's because Qt can't set the window opacity under Wayland.

Qt can set window opacity on wayland. I have a transparent panel and others (like terminal, dropdown, and even a file manager :laughing:) It is highly unlikely that a "compositor" does not support opacity.

Overlapping shouldn't be disabled based on the compositor. We already have an ugly instance of compositor check, which was inevitable; adding another instance would start a mess in the code.

Seconded. We should simply wait for some uniform protocol to develop. Until then, we call it a side-effect of wayland and march-on.

[tsujan]

Qt can set window opacity on wayland.

No, I meant setWindowOpacity(); otherwise, Wayland likes translucency — most of my windows are made translucent by the Kvantum widget style ;)

[marcusbritanicus]

Ah! That was something I gave up a long time ago - I always had compositing issues when I used it. But still, a widget can make itself translucent on wayland with a combination of QGraphicsOpacityEffect and little override of paintEvent(...).

I do not use QGraphicsOpacityEffect, but override paintEvent(...) to achieve what I need.