Unified module click handler

[patrick96]

Each module should support click-left, click-right and so on.

Modules that define custom actions (date, volume, ...) also support all actions and if an action is defined, it overrides the built-in action.This is only for actions that surround the whole module.
Action blocks that only surround parts (e.g. xworkspaces) are handled as before. Modules should offer an option to disable each of these actions.

Action blocks around the whole module can be disabled by setting the appropriate click-* key to the empty string

This will help reducing much of the code duplication that we have with click actions.
It will also make modules more flexible.

Should probably be tackled, after #1172 is solved.

EDIT: This will also resolve #273
EDIT2: There is a handle-events key in all modules (but it's only actually used by alsa and pulse). An implementation for this should either deprecate that key or incorporate it (meaning it shouldn't be loaded from the config in the constructor in base.inl but rather by whatever helper functions implement loading the click commands)
EDIT: This would deprecate enable-scroll in internal/xbacklight
EDIT: Anytime builder::flush is called, all open action tags are closed (e.g. progressbars do this). We need to make sure that we only close open action tags at the end of modules and not on every flush.
EDIT: This would deprecate enable-(click|scroll) in the internal/bspwm, internal/xworkspaces and internal/i3 modules. We will also need to think about what to do with reverse-scroll and wrapping-scroll.

EDIT: This will achieve #1942

EDIT: Tokens should also be available for these action keys, this will give an alternative for #887 and #2067. This will also require all tokens to be available in the entire module instead of limited per label.

Ref: #1521

[Nadrieril]

In case someone else wants this right now, it's possible to add custom click actions to existing modules using format strings. Took me a while to discover.
More details here: #273

[G-Rowell]

@patrick96

Heya!

Is there a current in-progress PR for this?

If not do you have a suggestion of where I should start?

GRowell (from the Gitter)

---

(It seems this is currently possible, but only through forwards compatibility with a specific Lemonbar format,
I'm not sure what the direction of this project is, if there is an aim to further support Lemonbar syntax or further develop the Polybar INI syntax.

(I support the latter IMO))

Thanks!

[patrick96]

There is currently no ongoing work for this.

The way that I imagined this going is that there is some shared code that takes care of loading the commands for all supported click actions (click-left, double-click-right, etc.) and that code can then also be used to directly produce the right output when the module output is created. The goal is that we don't have to duplicate code within modules (as we kind of do right now) to support click commands.

Have a look at how the script and ipc module currently support this. We basically want this generalized for all modules.
However, many modules define their own internal click actions (e.g. the two volume modules) so this gets a bit more complicated. I think initially we can just not support for example click-left if the module already defines an internal left click action.

This can probably take the form of a class that stores all the click commands the user has defined in a module.

Probably best to create a proof of concept in the script or ipc module for how this could look.

Let me know if this too vague ;)

---

The lemonbar syntax will be supported in the foreseeable future (it's also what we still use internally to format the modules). But we do want to give users the ability to configure their bar even without formatting tags.

[G-Rowell]

As Polybar supports inheritance,

presumably we could abstract this code to a root/base module?

(if I understand the code duplication issue correctly, that is).

---

Will take a look when I can, but I'm very busy right now sadly :(

Thanks for the tips, will likely ask a few questions at the end of the week or smth!

[patrick96]

There is no hurry, take your time :)

Yes, the base module code is one place to put this. But preferably this core functionality could be extracted into its own class for which each module has an instance in the base class (similar to what the action router is doing with m_router).

[redxtech]

Has there been any progress on this?

[atobi16]

I'd like to be able to open calcurse through the date module with a right click. Seconding the support request.