Overriding default click actions

[ammgws]

With the config below, right clicking on the sound block will trigger the default mute action as well as executing random_command2.

[[block]]
block = "sound"
[[block.click]]
button = "left"
cmd = "random_command1"
[[block.click]]
button = "right"
cmd = "random_command2"

Should the default click action just be overridden?

Also, should there be a way to remap or use the default action with another button, without reimplementing it via a command yourself? e.g.

[[block]]
block = "sound"
[[block.click]]
button = "left"
cmd = "{block_default_left}"

( I just made up the syntax to illustrate the point)

instead of having to do

[[block]]
block = "sound"
[[block.click]]
button = "left"
cmd = "pamixer --mute"

(That is just a simple example, the bluetooth block disconnect is probably less trivial)

[MaxVerevkin]

Should the default click action just be overridden?

Set pass = false to override block's action. Documented here (this should be mentioned somewhere in the README).

[MaxVerevkin]

Also, should there be a way to remap or use the default action with another button, without reimplementing it via a command yourself?

I imagine something like this could be implemented:

[[block]]
block = "sound"
# Left-click will toggle mute and _will not_ run custom command defined for right-click
[[block.click]]
button = "left"
redirect = "right" # Or `map_to` or something else
# Right-click will run a command and not toggle mute
[[block.click]]
button = "right"
cmd = "my_cmd"
pass = false

[ammgws]

Hmm, should we make pass be false by default?

[MaxVerevkin]

Hmm, should we make pass be false by default?

That sounds like a good idea

[ammgws]

I just noticed that when overriding the left mouse button click for music that it also overrides the click actions for the play/pause/prev "widgets", which IIRC didn't happen with v0.22 and earlier. I don't think there is a way around this atm, so I guess just have to document it?

[MaxVerevkin]

I would consider this as a bug. It shouldn't be too hard to make those buttons "special", but then we have to decide:

1. Should there be a way to override those buttons' actions?
2. nvidia_gpu also uses different widgets to implement "buttons". Should they be "special" too?

[MaxVerevkin]

Some more thoughts.

Suppose each block has an enum of "actions". For example, a sound block has

pub enum Action {
    Mute,
    IncVolBy(u8),
    DecVolBy(u8),
}

Instead of receiving a stream of "click events" each block receives a stream of it's "actions":

event = api.event() => match event {
    UpdateRequest => { ... }
    ActionRequest(action) => match action {
        Action::Mute => { ... }
        Action::IncVolBy(step) => { ... }
        Action::DecVolBy(step) => { ... }
    }
}

Then the user can assign any action to any button:

[[block]]
block = "sound"
[[block.click]]
button = "left"
action = "mute"
[[block.click]]
button = "right"
cmd = "pavucontrol"
[[block.click]]
button = "up"
action = "inc_vol_by(1)"
[[block.click]]
button = "down"
action = "dec_vol_by(1)"

[MaxVerevkin]

I just noticed that when overriding the left mouse button click for music that it also overrides the click actions for the play/pause/prev "widgets", which IIRC didn't happen with v0.22 and earlier. I don't think there is a way around this atm, so I guess just have to document it?

Supposing we go with my proposal, I think I have a solution for this. Currently we implement buttons by creating additional "blocks" with some integer "instance". Instead of some integers, we can use some meaningful names.

For example, music block has "main part" (without instance property), "prev", "play" and "next". By default [[block.click]] applies only to the "main part". But if the user wants to override them, they can write something like this:

[[block.click]]
button = "left"
widget = "..." # not sure about the name
cmd = "pavucontrol"

[MaxVerevkin]

This way we no longer need pass