Issue 3284: wlr/taskbar: deal with "sh: line 1: activate not found"

[RobertMueller2]

Related to issue #3284. Not closing from here, as there might be further problems.

Since PR #1977, both AModule and wlr/taskbar are handling on-click, on-click-right, on-click-middle. Since wlr/taskbar has internal actions "activate", "close", ... etc, wlr/taskbar performs those, and AModule tries to execute them as a command, this leads to messages like: sh: line 1: activate: command not found. (Interestingly, it seems to always happen for right click and middle click, I could never reproduce the message for left click and have not understood why this is the case.) If the action as such works against the compositor, it is still performed. But the error message might suggest an actual error situation, so it is somewhat confusing.

This PR addresses this in a minimally invasive fashion (I think anyway) by overriding doAction to do nothing. The challenge here was that AModule provides action handling for the whole module, but wlr/taskbar needs the event handling on the individual buttons so we can't really get rid of the existing event handling within wlr/taskbar easily. I feel that in the long run, there could be a Buttons mode for AModule, or an AButtonsModule extending AModule which could deal with this challenge. But that kind of change was a bit too big for my liking though, I don't even know if we have any other modules with individual buttons that would benefit from such a generic implementation. And I'm not that great a C++ coder. :p

The actions now have to be given within an action object, like this:

    "wlr/taskbar": {
      "format": "{icon}",
      "icon-size": 24,
      "all-outputs": false,
//      "on-update": "echo \"$(date) XYZ\" >> ~/xyz.log"
      "actions" : {
          "on-click": "activate",
          "on-click-middle": "close",
          "on-click-right": "activate",
      }
    },

Otherwise AModule would not call wlr/taskbar's overridden doAction. Existing configs still work in the same broken way, but will cause warning messages.

[RobertMueller2]

~I changed this back to draft, I realised I might have interrupted drag+drop in case no actions are configured. This will require a small rework.~

~I might also add some trace logging for future troubleshooting of actions not having an effect against compositors.~

Edit: all sorted now.

[RobertMueller2]

Marking this as draft again. There might be a use case to actually allow specifying a command, perhaps with the foreign toplevel id in the parameter or environment variable. I'm not aware if any such tools exist right now that can make use of the toplevel id, but it's a theoretical possibility at least.

[RobertMueller2]

Doesn't really work like that with the foreign toplevel id. But at least we can allow {app_id} etc for commands. That's in the PR now.

[RobertMueller2]

I'm closing this PR. I'm not using wlr/taskbar enough to keep up with additional changes, and I don't have enough spare time at this time to test any conflict resolved version.

If anyone wants to pick this up again, feel free to.