Comment 7 for bug 1180872

Hi RJ,
I think I got you point and I like it. But we have to be care full not to try to get confused with the different demands from that sort.

So let me collect the use cases first:

1) Indicate an individual control cannot accept changes (is fixed) because of a state inside Mixxx (read only)
2) Indicate (1 .. n) controls are not evaluated my Mixxx because of a state inside Mixxx (read only)
3) Drawer: Hide (1..n) controls because they are currently not needed for the specific setup or mixing style (read+write)
4) Hide or draw disabled (depending on Skin design) for (1..n) controls because they are not used in the specific setup (preferences)

Examples:
* Master Sync switch for an external clock source
    4) if no external clock source is configured
    1) if the external clock source is configured but not working
* EQs
    4) if EQ is bypassed
    2) if the Killswitch is enabled
* Mixer
    4) if an external Mixer is configured
* Play control
    1) if no track is loaded
* passthrough
    4) if no vinyl control is configured
* Deck 3+4
    4) if only two decks are configured
    3) if the decks are temporary not needed or they consume to much space.
* loop_in and loop_out
    1) if no loop is possible due to internal states
    3) if the DJ does not need Loops
* talkover button
    1) if mic is configured but not working
    4) if no mic is configured

Possible Solutions:

for 1) We have already a Request/Confirm path to reject co changes before the are adopted. Combined with the new indicator control, this looks like a suitable solution. Btw. this is the way the controller manufactures think. E.G Denon uses blink patterns for many controls like play and looping controls. It is fully suitable for midi controllers as well.

We have also discussed the option for showing a static disabled image instead of blink patterns.
I think his can be achieved by extending the toggle buttons with a third state "disabled" or by allowing to read the current blink pattern from the indicator control. Still unsure what is better.

for 2) I am not sure if we need a special solution for this. For our EQ example, you have already a visual feedback that the killswitch is enabled.The RQ knob is still working and this is fine to me.

for 3) Currently we use generic Skin controls for this. This is a fine solution for now. We may think about making the Skin defined controls more flexible later.

for 4) Here Your Idea of introducing new control to be tied to the disable state perfectly fits.