wlr/taskbar "on-click" "activate" has no effect, "activate" "on-click-right" says "sh: command not found". "close" is different.

[bashprompt]

waybar 0.10.3-1.1 hyprland 0.40.0-54.3 OpenSuse Tumbleweed Same behavior on EndeavorOS using same major release numbers

This behaviour started a few weeks ago.

on-click has no effect when set to "activate" on-click-right "activate" has no effect except terminal says "command not found"

// Taskbar
"wlr/taskbar": {
       "all-outputs": true,
       "format": "  {icon}  ",
       "tooltip-format": "{title}",
       "on-click": "activate",
       "on-click-right": "activate"
       },

If I change the action to "close":

       "on-click": "close",
       "on-click-right": "close"

on-click: "close" has no effect. No messages in terminal. on-click-right": "close" does close the app icon while saying "sh: line 1: close: command not found" in the terminal

Waybar started with --log-level=trace says this when trying "on-click": "activate":

[2024-05-20 08:41:10.462] [debug] hyprland IPC received urgent>>5652f3972620
[2024-05-20 08:41:10.463] [trace] Getting active workspaces
[2024-05-20 08:41:10.464] [trace] Updating workspace states
[2024-05-20 08:41:10.469] [trace] Selecting icon for workspace 1
[2024-05-20 08:41:10.469] [trace] Selecting icon for workspace 3
[2024-05-20 08:41:10.469] [trace] Updating window count

When trying "on-click-right": "activate" the output is:

[2024-05-20 08:44:08.030] [debug] Added child to reap list: 9633
sh: line 1: activate: command not found
[2024-05-20 08:44:08.036] [debug] Received SIGCHLD in signalThread
[2024-05-20 08:44:08.036] [debug] Reaped child with PID: 9633
[2024-05-20 08:44:08.160] [debug] hyprland IPC received urgent>>5652f3972620
[2024-05-20 08:44:08.161] [trace] Getting active workspaces
[2024-05-20 08:44:08.162] [trace] Updating workspace states
[2024-05-20 08:44:08.166] [trace] Selecting icon for workspace 1
[2024-05-20 08:44:08.167] [trace] Selecting icon for workspace 3
[2024-05-20 08:44:08.167] [trace] Updating window count

[bashprompt]

Looks similar to #3169, although #3169 also references a 2-yr-old fix, which appears to be no longer fixed?

[akhob]

I have the same issue started a few weeks ago.

Waybar v0.10.3 Hyprland v0.40.0 archlinux

[realizer5]

it began after waybar update

[realizer5]

how do i fix this issue?

[bashprompt]

For me, the fix was to stop using wlr/taskbar.

Reference the waybar wiki hyprland section and add app icons to workspaces. The downside is you need to write rules to assign glyphs to applications. The upside is the workspace area on waybar does the job that wlr/taskbar used to do.

I also use the hyprland/window module to provide a full window title of the active client.

"hyprland/workspaces": {
  "format": "<sub>{icon}</sub>: {windows}",
  "format-window-separator": "   ",
  "window-rewrite-default": " ",
  "window-rewrite": {
    "title<.*youtube.*>": "", // Windows whose titles contain "youtube"
    "class<firefox>": " ", // Windows whose classes are "firefox"
    "class<libreoffice.*>": "󰷈 ", // Windows whose classes are "firefox"
    "foot": "", // Windows that contain "foot" in either class or title. For optimization reasons, it will only match against a title if at least one other window explicitly matches against a title.
    "alacritty": "󰅬",
    "tilix": "",
    "Klondike": "🃏",
    "geany": "",
    "title<.*Trilium.*>": "🙪",
    "Telegram":"",
    "Bitwarden":"",
    "class<thunar>": "",
    "class<Pcmanfm>": ""
    }
    },

"hyprland/window": {
       "format": "🔷 : {}",
       "rewrite": {
               "(.*) — Mozilla Firefox": "🌎 $1",
               "(.*) - fish": "> [$1]"},
      "separate-outputs": true
      },

[hoanggbao00]

"wlr/taskbar": {
                //.....
        "tooltip-format": "{title}",
        "on-click": "activate",
        "on-click-middle": "close",
        "app_ids-mapping": {
            "firefoxdeveloperedition": "firefox-developer-edition"
        }
    },

mine is on-click-middle still can close that app. but the on-click to active that window not work.

waybar log:

[2024-05-28 08:45:38.913] [info] Unable to receive desktop appearance: GDBus.Error:org.freedesktop.DBus.Error.UnknownMethod: No such interface “org.freedesktop.portal.Settings” on object at path /org/freedesktop/portal/desktop
[2024-05-28 08:45:38.913] [info] Using CSS file /home/hoanggbao/.config/waybar/style.css
[2024-05-28 08:45:38.919] [warning] module : Unknown module: 
[2024-05-28 08:45:38.919] [info] Hyprland IPC starting
[2024-05-28 08:45:38.926] [info] Loading persistent workspaces from Waybar config
[2024-05-28 08:45:38.926] [info] Loading persistent workspaces from Hyprland workspace rules
[2024-05-28 08:45:38.931] [warning] module : Unknown module: 
[2024-05-28 08:45:38.931] [warning] module : Unknown module: 
[2024-05-28 08:45:38.939] [warning] module : Unknown module: 
[2024-05-28 08:45:38.939] [warning] module : Unknown module:```

[RobertMueller2]

I've had a look at this and at first glance I'd say there are two different issues.

The first, the lack of activation, is something I cannot reproduce (anymore?) with Waybar 64f54e1fcef76729b62fdacfec0b2baea56753c5 and https://github.com/hyprwm/Hyprland/commit/b7f42a1e88a5b6c9d2dbdba31e0f35f6a02461e7 (fairly recent, but not the latest :P)

Waybar uses zwlr_foreign_toplevel_handle_v1_activate and that has not changed in 2+ years. I think that makes it fairly unlikely that waybar itself broke the activation as such. But, to say this for 100%, either a source investigation, possibly assisted by bisect, in both Hyprland and Waybar would be necessary. I'm not sure that's a good forward looking approach for something that is (apparently) fixed, so I'll rather ask if you can try again with newer commits, I'm sure both programs have moved quite a bit since the issue was opened. ;)

For the second, sh: line 1: activate: command not found, I can reproduce this both with Hyprland and Sway. activate() in modules/wlr/taskbar.cpp is called alright AND the window is activated correctly via zwlr_foreign_toplevel_handle_v1_activate -- but AModule::handleUserEvent is called also. This can be seen with gdb and appropriate breakpoints in both files.

I'm not entirely sure yet why the same does not happen with on-click. But I think there needs to be a way for modules to use AModule's actions as well as define their own. Ideas:

• allow AModule's descendants to add actions to a blocklist which AModule then does not bind
• define a syntax that flags an action as internal, say instead of "activate" you'd say "@activate" and then AModule does not bind it.

I prefer the first one, because it does not break existing configs, but I need to have a look at how practical all this is.

[zeerayne]

For me this was fixed in hyprland 0.42+ and now is working fine