Alexays
wlr/taskbar update list on multi-monitor/workspace setup
Hi,
I'm using Hyprland + Waybar some years know, but this issue got never solved. I'm in the process of running out of patience.
Even it's an old issue, here are the currently used versions:
Arch Linux 6.14.6-273 Waybar 0.12.0 Hyprland 0.49.0
(yes, tried different packages)
The Problem is about 2 Monitors. Monitor 1 with workspaces 1-3. Monitor 2 with workspaces 4-6. Same waybar config for both Monitors.
If I launch any App it gets added to the taskbar. But it doesn't care about the monitor. Sometimes I launch one at Monitor 1 and it got listed on Monitor 2 and vice versa. Even if it get listed on the correct monitor, when I use movetoworkspace the taskbar doesn't get updated and entry stays on Monitor 2 even if the window is already at Monitor 1.
I move windows like this:
# Move active window to a workspace with mainMod + SHIFT + [0-9]
bind = $mainMod SHIFT, 1, movetoworkspace, 1
bind = $mainMod SHIFT, 2, movetoworkspace, 2
bind = $mainMod SHIFT, 3, movetoworkspace, 3
bind = $mainMod SHIFT, 4, movetoworkspace, 4
bind = $mainMod SHIFT, 5, movetoworkspace, 5
bind = $mainMod SHIFT, 6, movetoworkspace, 6
bind = $mainMod SHIFT, 7, movetoworkspace, 7
bind = $mainMod SHIFT, 8, movetoworkspace, 8
bind = $mainMod SHIFT, 9, movetoworkspace, 9
bind = $mainMod SHIFT, 0, movetoworkspace, 10
The only way to ensure the taskbar lists the windows correctly is by restarting waybar after launching a window or after moving around.
bind = ALT,W, exec, killall waybar && waybar &
screenrec: terminal gets launched at workspace 6 on monitor 0. taskbar is correct this time. then send to workspace 3 on monitor 1. taskbar did not update, window listed on wrong monitor. sending the window then back to workspace 6 on monitor 0 does indeed update the taskbar, but wrong. window is now listed on monitor 1, but it's already back on monitor 0.
thanks in advance
I'd suggest to run waybar with WAYLAND_DEBUG=1 to shed some light on this, ideally with a config for just wlr/taskbar to reduce noise.
I've tried to troubleshoot this a long time ago. For wlr/taskbar to have a chance to register a screen change, the compositor needs to send output_enter and output_leave of protocol zwlr_foreign_toplevel_handle_v1. Back then, Hyprland didn't in all cases. My first guess is that this is really a Hyprland issue, because I can't reproduce it with sway. Why again is this relevant? Because this is a client implementation of a protocol that both Sway and Hyprland speak on server side, and the issue only appears with one of them.
Since it is a long time ago, what you experience may of course be something different from what I attempted to reproduce back then.
EDIT: see #2993
I just reproduced it in a hyprland session, just using Debian package, didn't pay attention to version. Had to convert to mp4 because it's too big as a gif, couldn't be bothered to figure out how to reduce gif size.
Anyway, I hope this becomes apparent from the recording. There should be an enter/leave message, but it's only happening when moving the window with mouse. There is no such message when using hyprctl dispatch movetoworkspace. I suggest to report this issue at Hyprland.
It's also worth noting that when using hyprctl dispatch movetoworkspace, moving it back via mouse also doesn't trigger an enter/leave message. If one restarted Waybar between those two steps, it would be inconsistent even after a mouse move.
https://github.com/user-attachments/assets/fc338798-0a4d-4e69-b788-64061f1f070b
this seems to have been fixed in hyprland. i don't think it's released yet. https://github.com/hyprwm/Hyprland/commit/43966cc787c4a8844ac1e7affaadeedde8f4cc60
