Comment 5 for bug 1180872

> Is there a use case for the requirement to manually switch the disable state while paying life?

I think you may have misunderstood me -- I'm talking about making a way for Mixxx to communicate to the user that a control is disabled -- not the other way around. But your 2 use-cases are accurate -- although I would re-phrase your use cases as:

1) Indicate an individual control is enabled/disabled.
2) Indicate a group of controls are enabled/disabled.

Whether or not to show/hide widgets or to represent them in a disabled state (greyed out) is a choice the skin writer makes, not us. Hiding widgets may not always be desirable.

An example of use case 1 would be loop_in and loop_out COs. Clicking loop_out has no effect if there is no loop start position set or if the loop start position is after the current play position. Creating a disabled state or CO for the loop_out CO would allow the Mixxx engine to set its disabled state to true if there is no start position or if the current position is before the current loop start position.

Whether such a control is a one-off "enabled" indicator control (as hotcue_X_enabled is) or an "enabled" state built into ControlDoublePrivate is a question. The enabled state would be for consumers of the CO, not owners of the CO so we wouldn't have to spend extra CPU time checking the disabled state on every access in the engine.

This way, skin writers or preset authors could make the skin or controller give visual feedback for that case. Currently there is no way to know other than hard-coding the logic in your controller script or making a custom widget.

> For use case 2. we have already solutions in 1.11 eg. the talk over button.

I'm not sure what you mean -- the talkover button for the mic is exactly an example of where we fail today! You can click it regardless of whether there is a mic connected to Mixxx or not.

-----

There is another issue which has solidified my feeling that we need to use the QWidget "enabled" state: how to combine different enabled states. For example, if you tie the enabled state of the filterLowKill to filterLow, the widget will be enabled. However, if the user disables EQs entirely or some other state causes EQs to be disabled (e.g. no track is loaded to a deck) then we want the widget to disable regardless of the state of filterLowKill. The QWidget enabled state gives us exactly that through the hierarchical nature of the enabled state. A parent widget being disabled disables all of its children regardless of their individual enabled states.