Add a Toggle Menu item, and a icon change action for workflows or toggle state

[NotYetFound]

Description

Add an item type that behaves as a toggle,
one click performs the "on" action, the next click performs the "off" action. Example: a single tap mutes the mic, the next tap unmutes it.

Dynamic icon for items/workflows: Allow an item or workflow to update its own icon at runtime. Use cases:
Reflect toggle state (mic vs muted mic, dark mode on/off).
Show a temporary "running" icon while a longer workflow executes, then revert to the normal icon when it finishes.

Affected Desktop Environments

All

Additional Information

No response

[Schneegans]

Hi there! Thanks for the suggestion. This would be great indeed. The tricky part will be to determine the initial state of the toggle. How should Kando decide which state to use initially?

[NotYetFound]

Not sure if this is what you meant, but what about a simple default state per toggle item, or the user can set a command that returns true/false to set the state automatically? That runs on menu open and or on toggle. With an invert option for when the command’s output is opposite to what you want.

[Schneegans]

Yeah, this could be possible. However, the script would need to be run every time the menu is shown, as the state could also be changed by other means, for instance by toggling the mic in your system settings or so.

[NotYetFound]

Yeah, The only thing would be a slow script making the menu lag. It could probably run in the background and update the icon/state once it’s done? For toggles without a command set, it could just fall back to a default or alternate each time. And if the command outputs an error, maybe show an error icon so it’s obvious something’s off instead of guessing the state.

[NotYetFound]

One limitation though: the command/auto-state side is pretty Linux leaning, and it only works when the state is actually queryable. Something like a Discord mute I toggle with a keybind from Kando has no way to read the state back, so those would just rely on the default/alternate behaviour. Probably fine as long as that’s treated as an expected fallback rather than something meant to always stay in sync. One thing is the toggle could only trigger commands to help with desync which is fine but limits stuff.

[Schneegans]

Yeah, in many cases it will be easier to just have two menu items next to each other: one turns something on, the other off. This is much easier and will work in all cases. But at some point I also want to have sliders for numeric input, and these are much more complicated even. And at this point, we can also add toggles, I guess. They will have similar configuration issues.

[NotYetFound]

Yeah, that’s fair. two items work, and it's better than something that desyncs I guess.