Question: I have a combo which is disabled, but adding an element to it will emit the `currentIndexChanged(int)` signal.

I expected signals to be naturally turned off when a widget is disabled, but it's not the case. I know there is `blockSignals(bool)`, but if there are many widgets whose signals must be "blocked when disabled", `blockSignals` would require a Boolean state for each widget.

How can I disable the signals sent by a widget when it is disabled (and not alter its `blockSignals` state)?

EDIT
To clarify: since this is a widget, user cannot interact with it when it's disabled, *but* some signals are emitted when altering the widget programmatically. In my case there are two interesting signals:
`currentIndexChanged(int)` and `activated(int)`

The problem in my code is that I sometimes alter the combo programmatically AND I wish it to emit a signal, and sometimes it's the user that alters the combo by interacting. That's why I am using `currentIndexChanged` and not `activated`.

In both cases, anyway, I don't want the signals to be emitted when widget is disabled.

Answer: 
You can disconnect signals with the `QObject::disconnect();` when you want to block them and then reconnecting them when you want to unblock them.
In your case, the signals are the sole source of state information carried on to other objects. If you disable them, the other objects won't ever get any notification that the state was changed. This can cause bugs in the objects that depend on being informed of your widget's state.

There are at least two solutions:

1. Don't change the widget's state. You can certainly defer the update of the widget's contents until after it gets reenabled.
2. Create a proxy that monitors the originating widget's state, and queues up the signals (with compression) until the widget gets reenabled.

Due to those workarounds, your design may require a rework. Perhaps it'd be better if you could cope with signals from those disabled widgets. You should also evaluate whether disabling a widget doesn't break the user experience. What if the user wants to see the contents of a widget, but doesn't mean to change the current setting? A disabled widget in such a case is going too far. You can make you own, perhaps subclassed, widget, acting so that the control is not disabled, but the current element stays fixed. This could even be a separate object, applicable to any control - through judicious leverage of the user property.