Details
-
Bug
-
Resolution: Won't Do
-
P2: Important
-
6.3.0
-
None
-
-
4e7a83156 (dev)
Description
From: https://codereview.qt-project.org/c/qt/qtdeclarative/+/399320/comment/ae61a8d6_524d11b7/
Item { id: p1 palette { disabled { windowText: "blue" } } Item { id: item1 palette { disabled { text: "red" } } } } Item { id: p2 palette { disabled { windowText: "yellow" } } Item { id: item2 palette.disabled: item1.palette.disabled } } Rectangle { width: 100 height: 200 color: mouseArea.pressed ? item2.palette.disabled.windowText : item2.palette.disabled.text MouseArea { id: mouseArea anchors.fill: parent onDoubleClicked: { // Error: Cannot assign [undefined] to QQuickColorGroup* item2.palette.disabled = undefined } } }
The palette of item1's disabled state is assigned to the disabled state of item2's palette. Although we only set the "text" of the disabled state to "red" in item1, and do not modify the color of its "windowText", but set "windowText" of disabled state in its parent p1. In this example, what is the your expected value of "item2.palette.disabled.windowText"? Is it be "blue" from p1 or "yellow" from p2? From the code of QQuickPaletteColorProvider::copyColorGroup it can be deduced that it is actually "blue", but only from the qml code in the example we can't get the answer.
In addition to being difficult to determine its behavior, when we use "palette.disabled: item1.palette.disabled" to assign other objects to the disabled of item2's palette, we unable to restore it, because these properties of QQuickPalette have no Add RESET field. Of course it's easy to fix, but I'd say it's not a good design, and I don't see where this feature is used, at least not at all in our code, nor a unit test case for it. If we can ignore compatibility, then my suggestion is to set the properties in QQuickPalette to read-only, and do not allow the use of "palette.disabled: item1.palette.disabled", it can be "palette.disabled" .text: item1.palette.disabled.text” instead, but we can't ignore compatibility, so how do we fix this?