3.3 Beta /Mac: clicking "OK" in color dialog puts mouse in drag-mode, ESC doesn't fix it (recent REGRESSION).
Reported version
3.x-dev
Type
Functional
Frequency
Once
Severity
S3 - Major
Reproducibility
Always
Status
closed
Regression
Yes
Workaround
No
Project
In 3.3 Beta, Mac, click on any element and open the color dialog from the color swatch. Click on a color, and click OK (don't use keyboard, use mouse/trackpad). The mouse pointer is now in "drag" mode, and moving it will drag the palette panel boundary, and ESC doesn't fix it. It is possible by careful clicks to free the mouse, but the palette panel boundary will remain damaged.
This is a new REGRESSION.
Fix version
3.3.0
Comments
Fixed in branch master, commit 578d4a9659
_fix #295121: crazy behaviour of the colorLabel
Rewrite ColorLabel to be a child of QPushButton instead of QFrame. The reason is that QFrame doesn't implement MouseClickEvent. That led to the issues when opening the colour picker widget on mousePressEvent.
I have to move
Awl::ColorLabelelse ifstatement checks above theQPushButtonones, because the latter set incorrect connects for theColorLabelwhich inheritsQPushButtonnow._In reply to (No subject) by Jojo-Schmitz
Yay! :) Thanks, Anatoly!
Fixed in branch 3.3rc, commit 5eacfa167b
_fix #295121: crazy behaviour of the colorLabel
Rewrite ColorLabel to be a child of QPushButton instead of QFrame. The reason is that QFrame doesn't implement MouseClickEvent. That led to the issues when opening the colour picker widget on mousePressEvent.
I have to move
Awl::ColorLabelelse ifstatement checks above theQPushButtonones, because the latter set incorrect connects for theColorLabelwhich inheritsQPushButtonnow._Automatically closed -- issue fixed for 2 weeks with no activity.