pcmanfmqt --desktop with layer-shell-qt: no tooltip, no keyboard interactivity about labwc

[johanmalm]

Now, with layer-shell-qt6 and without any rule, Waybar always pushes the desktop downward, whether it starts after or before the desktop. It makes no difference if the background layer (current code) or the bottom layer is chosen in the code of pcmanfm-qt's desktop: it's always pushed downward by Waybar.

Set exclusive zone to -1.

Ref:

• https://wayland.app/protocols/wlr-layer-shell-unstable-v1#zwlr_layer_surface_v1:request:set_exclusive_zone
• https://github.com/swaywm/swaybg/blob/80ed4b020adfb0846f780faba95fc5cc9a770a18/main.c#L269

From protocol:

If set to -1, the surface indicates that it would not like to be moved to accommodate for other surfaces, and the compositor should extend it all the way to the edges it is anchored to.

A wallpaper or lock screen might set their exclusive zone to -1, so that they stretch below or over the panel.

[tsujan]

@johanmalm, thank you so much! Setting the exclusive zone to -1 solved the issue.

[tsujan]

I think all issues pointed out here have been fixed

Yes, they have :)

[tsujan]

I confirm @stefonarch's observation. The longer story (as a context):

Today, layer-shell-qt6 came to Arch at last. Its usage was straightforward. So, we happily applied the attached patch to the Qt6 branch and removed the window rules of pcmanfm-qt's desktop from rc.xml. Anchoring and layer setting were OK, but Desktop didn't have keyboard focus when needed, no tooltip either. Later, to my great surprise, @stefonarch told that everything was OK under kwin_wayland V6. I tested with my kwin_wayland V5, and yes, Desktop had a correct keyboard focus when needed, as well as tooltips.

[Consolatis]

Hm.. It seems we do indeed not set the keyboard focus correctly on layer surfaces < top layer: https://github.com/labwc/labwc/blob/master/src/layers.c#L121

I am not sure I follow the logic for the && layer_surface->current.layer >= ZWLR_LAYER_SHELL_V1_LAYER_TOP) condition on the top branch. Shouldn't that branch just check for layer_surface->current.keyboard_interactive != ZWLR_LAYER_SURFACE_V1_KEYBOARD_INTERACTIVITY_NONE?

CC @johanmalm

[stefonarch]

Testing wayfire I see it's fine too there.

[johanmalm]

Thanks for reporting. Looks like we've got some sorting out to do here for the on_demand case.

Hm.. It seems we do indeed not set the keyboard focus correctly on layer surfaces < top layer: https://github.com/labwc/labwc/blob/master/src/layers.c#L121

I am not sure I follow the logic for the && layer_surface->current.layer >= ZWLR_LAYER_SHELL_V1_LAYER_TOP) condition on the top branch. Shouldn't that branch just check for layer_surface->current.keyboard_interactive != ZWLR_LAYER_SURFACE_V1_KEYBOARD_INTERACTIVITY_NONE?

CC @johanmalm

The exclusive case treats top+overlay lay differently in the definition. I can't remember, but guess I just followed that when I first wrote it (see link below).

https://wayland.app/protocols/wlr-layer-shell-unstable-v1#zwlr_layer_surface_v1:enum:keyboard_interactivity:entry:exclusive

Feels like we ought to honour click-to-focus semantics for on_demand for all layers.

Suggest we do that after Friday so it's get plenty of testing before release.

[johanmalm]

Very exciting that layer-shell-qt6 is out in the Arch repo. Feel like a big step in wayland native desktop components (supporting Qt popups)

[tsujan]

Feel like a big step in wayland native desktop components

Yes, indeed :)

[Consolatis]

The exclusive case treats top+overlay lay differently in the definition. I can't remember, but guess I just followed that when I first wrote it (see link below).

https://wayland.app/protocols/wlr-layer-shell-unstable-v1#zwlr_layer_surface_v1:enum:keyboard_interactivity:entry:exclusive

Hm, right. So I assume we need to treat ONDEMAND the same as EXCLUSIVE && layer < top.

Suggest we do that after Friday so it's get plenty of testing before release.

Yes, absolutely.

[johanmalm]

Hm, right. So I assume we need to treat ONDEMAND the same as EXCLUSIVE && layer < top.

Aye. I think so.

[stefonarch]

It looks there is a similar issue in lxqt-panel too (branch wayland-taskbar): main menu and other menus can't be navigated by keyboard.

[Consolatis]

It looks there is a similar issue in lxqt-panel too (branch wayland-taskbar): main menu and other menus can't be navigated by keyboard.

You may be able to work around that by using the top layer for the panel. However that is not recommended as a permanent fix, we need to fix labwc.

Edit:
Actually, this seem to be something else, the code path I posted above is only called during map or change of keyboard interactivity. It still needs to be fixed but that is not really the issue here. I assume what happens is that we are actually talking about layershell subsurfaces. I completely forgot about that but we removed the code path that allows clicks on them to give keyboard focus to "fix" #1131. We then didn't follow-up on that to implement a proper fix (e.g. find the root layershell surface of a layershell subsurface and then use that one to check for the keyboard interactivity). We should likely also make process_keyboard_interactivity() public and call it from src/input/cursor.c.

In general our layershell focus handling for subsurfaces need a bit of work, if we restore the ability to focus layershell subsurfaces we also need to make sure to not accidentally remove theactive state from other windows at focus_change_notify() (so we don't reintroduce #1131).

[stefonarch]

I completely forgot about that but we removed the code path that allows clicks on them to give keyboard focus to "fix" #1131

I see some regressions switching from Neon with labwc 0.6.5 to arch, indeed keyboard navigation works there in panel menus (with one exception in fancymenu: left-right arrows).

Afaik the panel is on top level. But other compositors like wayfire and sway have the same keyboard issue too, only kwin_wayland get't it right.

Opened #1572

[droc12345]

What do the standards say about it?
I'm not in favor of following whoever, unless they're following standards.

[tsujan]

There's also a strange thing, which may be not related to this report.

Previous to layer-shell-qt6, I used this rule:

    <windowRule identifier="pcmanfm-qt" title="pcmanfm-desktop0">
      <skipTaskbar>yes</skipTaskbar>
      <skipWindowSwitcher>yes</skipWindowSwitcher>
      <fixedPosition>yes</fixedPosition>
      <action name="MoveTo" x="0" y="0" />
      <action name="ToggleAlwaysOnBottom"/>
    </windowRule>

Then, if I started pcmanfm-qt's desktop before Waybar, Waybar was decently drawn over it, at the top edge of the screen.

Now, with layer-shell-qt6 and without any rule, Waybar always pushes the desktop downward, whether it starts after or before the desktop. It makes no difference if the background layer (current code) or the bottom layer is chosen in the code of pcmanfm-qt's desktop: it's always pushed downward by Waybar.

I don't know if this also happens with other apps that can draw the background but, Intuitively speaking, one expects that a dock shouldn't displace what's on the background, regardless of the order of starting — as is the case under X11.

[johanmalm]

I've written a small Qt6 test panel and tooltips show on that one, so not sure what's going on with that.

Regarding popup keyboard-interactivity, I think it's the same story as with #1572, so suggest we carry on that discussion there only. See #1572 (comment)

[Consolatis]

I think all issues pointed out here have been fixed by the layershell focus rewrite.
AFAIR there was only one thing remaining that is tracked #1572: focusing the desktop of there is nothing else to focus.

Closing this for now, if I missed something please feel free to open a new issue.