Expose button background color as variable / condition

[Thomosaurus6]

Is this a feature relevant to companion itself, and not a specific module?

• [x] I believe this to be a feature for companion, and is not specific to a module

Is there an existing issue for this?

• [x] I have searched for similiar existing issues

Describe the feature

I’d like to request a way to read the current background color of a button in Companion.

Requested features: • A variable that exposes a button’s current background color value • Or a condition “Button color equals [value]” • Ideally usable inside triggers, conditions and expressions

Usecases

We often use buttons as visual feedback indicators (tally, router state, presets etc.). In more complex setups, the button color itself represents the final state after multiple conditions or layers have already been resolved by Companion. Right now, there is no way to use that resulting color as a condition or trigger.

Let’s say a camera becomes live. A button already turns red because it combines different module feedbacks for physical and virtual sources. That button color is the correct, unified indicator of the state. But currently we cannot use “Button X is red” as a trigger condition or a variable. Instead we have to rebuild the logic that produced the red color, inside the trigger system. This is more complicated and error-prone.

[dnmeid]

@Julusian, you added this to the plan. Do you really think it is a good idea that way? As far as I can see, I'd say this request is quite valid just because of some current shortcomings of the feedback system. Thomosaurus writes that he thinks the resulting color is a "state", but that is wrong. The color is only an expression of style and feedbacks. Additionally with graphics overhaul in the future the one and only background color will be replaced. I think with some concepts of graphics overhaul the intention of the request will be possible. If the color of an element can be expression driven, you can also use this expression to write a local variable and then use this variable in the requested way.

So I'd say no to: feedbacks -> color -> variable
But yes to: feedbacks -> variable -> color

[Julusian]

I added it there as something that will be closed by that milestone one way or another.

After doing that I did start thinking about whether this is already solved by expression variables, but I dont think there is a way to get a colour from a variable to be used by a button (except for by that epic), then I got distracted by a meeting.

So yes, I agree that feedbacks -> variable -> color is the correct approach which the overhaul already unlocks, but I dont think this can be closed until that has at least landed in beta