Lxqt-Panel hiding is broken with i3

[iamthesenate1]

I'm submitting a…

[x] Bug
[ ] Feature Request
[ ] Documentation Request
[ ] Other (Please describe in detail)

Current Behavior

In lxqt there is an option of hiding the panel. While using i3 and picom as the compositor and trying to enable this feature, the panel was hidden, but the space was not reclaimed. Here is a screenshot to exemplify the issue:

Expected Behavior

i3 should reclaim the space when lxqt-panel is hidden.

Reproduction Instructions

Use LXQt with i3 as the WM.
Enable hiding in the lxqt-panel settings. Disable reserve space option if enabled.
The panel is hidden but the space is not reclaimed by i3.

The corresponding lxqt issue is: lxqt/lxqt-panel#1663 (comment)
Note that one of the LXQt deveopers that answered me said this:

We use Qt's and KWindowSystem's methods in lxqt-panel — nowhere we have WM specific codes.

Environment

Output of i3 --moreversion 2>&-:

i3 version: Binary i3 version:  4.19.2-78-g39376a94 © 2009 Michael Stapelberg and contributors
Running i3 version: 4.19.2-78-g39376a94 (pid 787)
Loaded i3 config: /home/manjaro/.config/i3/config (Last modified: Sb 18 sep 2021 20:10:36 +0300, 93132 seconds ago)

The i3 binary you just called: /usr/bin/i3
The i3 binary you are running: /usr/bin/i3

Config file

https://pastebin.com/kPR7wiC5

Logfile URL:

- Linux Distribution & Version: Manjaro Linux with unstable repos
- Are you using a compositor (e.g., xcompmgr or compton): Picom

[iamthesenate1]

Are logs really necessary in this case?

[Airblader]

I don't see why not. They'll provide information on the exact sequence of events and what the client (and i3) is doing.

For the record, the statement by the devs is of course somewhat ridiculous — i3 also has no code specific for lxqt-panel, that doesn't mean that it's clearly not i3's fault. It's not like toolkits like Qt never have had any bugs, and the X world is a bit more complicated than that, for example window managers aren't required to support all protocols.

The bottom line is that we need to know what exactly the client is wanting to do here on X level and what state it is in at that point. For example, what exactly does "hiding" here mean: unmapping the window? Logs are one way of doing that.

[Airblader]

That said, this is likely a duplicate of #4153, but we'll treat them as separate until that is proven.

[iamthesenate1]

Ok.
I will provide the logs soon.

[iamthesenate1]

Done!
i3-log.gz

[Airblader]

Since this file spans 12 minutes and 35,000+ lines, can you either generate one with a minimal amount of runtime and/or annotate timestamps of when you did what (specifically the timestamp at which the panel is hidden)? That would help identifying the relevant parts.

I'm also seeing some messages for unknown atoms from lxqt-panel, your output of xlsatoms from the same session would also be good to have to identify what lxqt-panel is doing there.

[iamthesenate1]

Done!
i3-log.gz
I have oppened the lxqt session.
I started picom using dmenu.
I hovered the mouse over the panel and then I have oppened qterminal to get the log output.

[iamthesenate1]

Here is the output of xlsatoms:
xlsatoms.gz

[Airblader]

Thanks! I don't see any requests made by the client that would make me believe any space should be free'd up, it just requests to be reconfigured to the same geometry several times (each time on the bottom with a height of 32px).

The requests with unknown atoms are for _NET_WM_STATE_ABOVE and _NET_WM_STATE_BELOW, neither of which i3 supports; we're also not claiming support for these in _NET_SUPPORTED, so the client shouldn't be expecting this to work.

If I had to guess I would say that lxqt-panel is probably using _NET_WM_STATE_BELOW to intend to hide the bar by allowing other windows to cover it up, though I'm not sure what causes the client to become invisible. Since that only seems to happen with picom (right?), it might be that picom causes that. You could try using xwininfo to grab the window ID of lxqt-panel, and once it stopped rendering issue xprop -id $id and xwininfo -id $id so we can inspect the atoms set on the window at this time.

Whether the client chooses to have fallback behavior or not is of course entirely their decision. If lxqt-panel insists on support for this atom for panel hiding to work, they should (IMO) check for support of the atom before offering that option. In any case the client should not stop rendering, but who to blame for this depends on what (presumably) causes picom to give it an opacity of 0.

Your picom config would be relevant at this point as well. Perhaps you have configuration that makes all windows with _NET_WM_STATE_BELOW entirely transparent? But since we reject the request the atom should never even be set on the window.

[Airblader]

A useful piece of information could be to figure out which Qt (or whatever toolkit) methods lxqt-panel is using when hiding the panel, as that should allow us to just look up directly (in the toolkit) what is supposed to happen (as opposed to guessing what I think might be happening, since I can of course be wrong).

I don't really want to dig into lxqt-panel's source code, however, so either someone else would have to do this or ask the developers for that information.

[Airblader]

FWIW, if my theory is correct, then i3 behaves entirely the way I would expect it to. Not only do we not support _NET_WM_STATE_BELOW, but even if we did, it'd be questionable whether the correct way to support it would be by removing it from the layout altogether. This atom is not intended to remove a window, but to push it back in the stacking order.

[iamthesenate1]

picom (right?)

Yes. Something that I must mention is that once picom is started, lxqt-panel becomes transparent(invisible), but if i right click or press anywhere a button is supposed to be, it is clicked(for example the start menu)

[iamthesenate1]

Once transparent, it never becomes visible again.

[iamthesenate1]

Output of xprop -id 0x1e00007: https://pastebin.com/NiHubU5j
Output of xwininfo -id 0x1e00007: https://pastebin.com/LG2TmPne

[iamthesenate1]

Picom config (I took it from the internet, used just for testing): https://pastebin.com/fphRHu1X

[Airblader]

_NET_WM_WINDOW_OPACITY(CARDINAL) = 0

That's why the panel is invisible. I don't know who sets this (i3 definitely does not), that is something to clarify with picom and/or lxqt-panel.

But that'd only fix the panel being invisible. For the actual hiding we'd have to figure out what lxqt-panel is actually doing to confirm my theory or figure out what is happening instead. From the i3 logs everything appears to be OK.

[iamthesenate1]

A useful piece of information could be to figure out which Qt (or whatever toolkit) methods lxqt-panel is using when hiding the panel, as that should allow us to just look up directly (in the toolkit) what is supposed to happen (as opposed to guessing what I think might be happening, since I can of course be wrong).

I have asked one of the LXQt developers this question and here is the answer: lxqt/lxqt-panel#1663 (comment)