Details
-
Sub-task
-
Resolution: Out of scope
-
Not Evaluated
-
None
-
None
Description
Olivier Goffart: QWidget::setEnabled behave as documented since Qt exists, and this has not shown to be a problem in the past. We have no plan to change this well-estabished behaviour.
Fair enough – it's a very good reason to keep setEnabled() untouched.
How about this: I would like to ask you to add to QWidget a new property, "enabledAllowed". Just as "enabled" is about widget attribute WA_Disabled:
inline bool QWidget::isEnabled() const { return !testAttribute(Qt::WA_Disabled); }
"enabledAllowed" would be about widget attribute WA_ForceDisabled:
inline bool QWidget::isEnabledAllowed() const { return !testAttribute(Qt::WA_ForceDisabled); }
The change which I suggest this time does not change anything about "setEnabled()" and "enabled". It only adds a new property to QWidget. This also enables fixing the behaviour of QtDesigner (which does not handle "enabled" in a consistent way at the moment).
Parent issue QTBUG-11534 and related QTBUG-11154 and QTBUG-11267 give examples of problematic behaviour of QtDesigner which are fixed by this patch. The designer-related changes in this patch are described in the last part of the description of the parent issue. But note that the new property is not QtDesigner-related and is very useful anyway (the possibility of fixing the problems in QtDesigner is simply an example of why this property is worth introducing).