[Development] suggestion: very small api change in QWidget

[Marek Wieckowski]

Hi,

An old issue [1] but one which maybe might be picked up still before
5.0? Sorry for disturbing this mailing list, but because of Widgets
being "done", it will be hard to change anything there without getting
some general attention. :) And solving the problem involves a small
api change, so this list seems relevant.

I would like to suggest a very, very small change in the way
WA_ForceDisabled and WA_Disabled are represented as properties of a
widget. This change would _not_ change anything at all in how
"enabled" works/behaves (how it is propagated from parent widgets to
children etc.). It's only about how it is represented as properties.

First, to show a use case, let me present you a "bug in designer"
(which is not really a bug in designer after all, the problem just
shows up there...). Too keep focused I'll describe what happens in
designer of Qt5 (but Qt4 is also wrong).

Open attached form in designer. It has three disabled widgets: group
box and two child buttons. Select e.g. the second push button and
change it's property "enabled" to true (checkbox checked). If you
select the other button or parent group you will see that they all
three have "enabled" checked. Now save the form and look at the .ui
file. For all three widgets you will see...
        <property name="enabled">
         <bool>false</bool>
        </property>
You see checked checkboxes in designer, but saved form has "false".
Funny not. Hope I got your attention. (To make this mail a bit
shorter, below I'll only look at the saving, not at why all 3
checkboxes got checked.)

The issue already got understood, I think, so let me make a short summary:
* basically the widgets have two distinct features represented by two
distinct attributes WA_ForceDisabled and WA_Disabled (which is fine);
* we have always been setting one of them (WA_ForceDisabled), but the
one which determined how widgets behave (whether they are actually
enabled) was WA_Disabled and which is determined based on
WA_ForceDisabled of our widget and all its parents (which all is
fine);
* but in property system these two distinct features are represented
by one property "enabled", with read function enabled() showing
!WA_Disabled and write function setEnabled() setting ... a different
feature, WA_ForceDisabled;
(see also the comment [2] which breaks the logic down more carefully
into smaller steps)

This is basically what derails designer in the above example, and what
could break any tool which would like to manage properties
automatically:
* designer keeps track of which properties were edited manually;
* when saving a form loops over them, calls the read function (here
enabled() ) and saves the result.
In the case of my form I've edited "enabled" of the button (toggled it
to be _set_), but when saving the form the designer reads enabled()
and gets _false_ because this button is disabled (because it's parent
was disabled).

If we had two properties:
1. "enabledAllowed" (or whatever name you choose, but something
representing !WA_ForceDisabled);
2. "enabled" (as it is now, representing !WA_Disabled)
and if setEnabled was a write function for enabledAllowed and enabled
would have no write function, then everything would be clear from
property-system point of view and tools which manage properties
automatically (like designer) would not get confused:
* the only property you can edit would be enabledAllowed (nothing
changes: we have always only been able to influence WA_ForceDisabled);
* it would not depend on any other widgets, so if designer "remembers"
that it was edited, it would then get and store correct value in .ui
(which then later would call setEnabled() with correct value).

Again, the comment [2] explains a bit more. See also an attached
example patch to qtbase. It just exposes WA_ForceDisabled as a
property. Does not change in the slightest bit how "enabled" is set,
propagated etc. And even though it does not change anything in the
designer [3], after applying it designer behaves beautifully (just try
it!)  and clearly enables editing which widgets are enabled. :)

Best,
~Marek

[1] https://bugreports.qt-project.org/browse/QTBUG-11576 and related
QTBUG-11593, QTBUG-11267

[2] https://bugreports.qt-project.org/browse/QTBUG-11576?focusedCommentId=119317&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-119317

[3] the second patch, to qttools is just a few lines to add support
for reading-in old forms and is kind of a cake-icing bit if something
similar to the first patch is accepted
-------------- next part --------------
A non-text attachment was scrubbed...
Name: patch1-qtbase.patch
Type: application/octet-stream
Size: 2304 bytes
Desc: not available
URL: <http://lists.qt-project.org/pipermail/development/attachments/20120420/0987dc92/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: patch2-qttools.patch
Type: application/octet-stream
Size: 1151 bytes
Desc: not available
URL: <http://lists.qt-project.org/pipermail/development/attachments/20120420/0987dc92/attachment-0001.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: QTBUG-11576-example.ui
Type: application/octet-stream
Size: 1570 bytes
Desc: not available
URL: <http://lists.qt-project.org/pipermail/development/attachments/20120420/0987dc92/attachment-0002.obj>