Enable/Disable Buttons

[officialmattsnyder]

Describe the feature The ability to enable or disable particular buttons (maybe even actions within a button?) - Basically, exactly the same functionality as exists at the instance level, just applied to buttons. I think some kind of enable/disable checkbox in the button editor is probably the best way to accomplish this from a UI perspective. Some kind of visual status indicator on the button itself would also be nice (disabled buttons are grayed out or something).

Is this platform dependent (windows, mac, ..)? Nope

If documentation is required to implement, do you know where to find it? I don't, but I'd guess it's probably just a modification of the existing instance enable/disable function.

Usecases -Users would be able to disable specific buttons (actions?) when not needed to prevent accidental triggering. -Potentially could also be used to provide an "arm/fire" configuration for certain buttons that want to avoid accidental triggering. The first button press enables a second button that is disabled by default. That second button then executes some actions. Would be nice for executing stuff like system shutdowns or emergency protocols.

[issue-label-bot[bot]]

Issue-Label Bot is automatically applying the label Enhancement to this issue, with a confidence of 0.97. Please mark this comment with :thumbsup: or :thumbsdown: to give our bot feedback!

Links: app homepage, dashboard and code for this bot.

[stevespaw]

Yes Please, this would be a time saver! When building a list for a button - quick testing of something is working or not!

[robsumm]

Yes please 😊

[jorbje]

I agreee 100% to this feature request.

[Suenee]

Hey, it will be nice and helpful, if I can enable/disable button upon an other event.

[Julusian]

I think this has some simiarities to #1411, and it definitely needs some prototyping to figure out how it should work.

I am unsure if this is a good way to go, or if this will be sufficiently handled by #1052. The advantage of achieving this with #1052, is that it will be up to the user to define how/if the button look should change from this.

But if this task does get done, I think that someone needs to put some time into doing some prototyping of how the visual side of this will work. This should be entirely possible using a combination of photoshop, to simulate how things will draw, and testing button styles on a streamdeck to compare enabled and disabled buttons.

Try to think about and play with differing styles of buttons (eg, white on black, black on red, text on bright/dark png).

Some more of my thoughts on things that need thinking about:

If buttons are greyed out when disabled, how much should they be greyed out? Will this cause confusion if using different colour palletes? Will white on black and grey on black be different enough to identify? What about where we don't have a full display? xkeys work by sampling the background colour. If the 'dimming' isnt 50% or more, the buttons there won't show any different. Or the encoders on the streamdeck+ or loupedeck, where there is no corresponding display.

for the admin ui, it feels like we should do something more invasive to make it really obvious. a giant red cross through the button? that feels like it will be too ugly, but dimming will make it almost impossible to find which ones are disabled. or maybe we do that, but make it be a toggle to show that indication? some work is needed here to figure this out.

[Jibun-no-Kage]

Please implement this!

[Suenee]

I came up with a solution that seems very universal to me (see the picture above):

• Add switch Enabled / Disabled
• Add tab "Disabled/Enabled": This tab will contain the following options similar to the "Step 1" tab:

TIRGGER ACTIONS when ENABLED: (tirggers by switching to the ENABLED state) Internal: Button: Visibility [ Target, Visibility: FALSE ]

TIRGGER ACTIONS when DISABLED: (tirggers by switching to the DISABLED state) Internal: Button: Visibility [ Target, Visibility: TRUE ]

PRESS ACTIONS when DISABLED: (tirggers when PRESS button is in DISABLED state)

RELEASE ACTIONS when DISABLED: (tirggers when RELEASE button is in the DISABLED state)

This could offer possibilities for user creativity:

• Switch Enabled / Disabled shows the current state of the button and offers the option to switch the state manually. If it is in the ENABLED state, all actions are performed as before. If it is in the DISABLED state, the action from the "DISABLED/ENABLED" tab is performed, as described next.
• Simply switching the state of the ENABLED/DISABLED button will trigger the actions TRIGGER ACTIONS when D/E . This allows me to change the appearance of the button. We already have functions that can change the appearance of the button. I can also add some other actions that must take place by switching to the desired state.
• Furthermore, I have the option to create my own reaction of the button to PRESS/RELEASE ACTIONS when DISABLED, if it is in the DISABLED state. I can, for example, use H2R-Graphics to write a message or play a warning sound. The button can also be unresponsive, which is probably the most desired.

Internal: Button: Visibility [ Target, Visibility: TRUE | FALSE ] It would be nice to add the VISIBLE/INVISIBLE function. In the INVISIBLE state, the complete description/visual of the button disappears, but it remains in memory. I can then restore it easily. This function does not affect the behavior of the button. It only resolves whether it is completely visible.

As @Julusian asked, there may be some preset in the basic configuration, how the button should behave in the DISABLED state. Typically, probably change the background color and not react. However, the user can change this behavior according to the above suggestion.

I find this solution very flexible, because each of us may have a different idea of ​​how the DISABLED BUTTON should react. My proposal assumes that the user can determine his own reaction.