I'll wait for you to investigate the bug before looking into it myself :)
Please also specifically mention if you're tackling problem 1, problem 2, or both (I'm not sure how related they are - maybe it should be 2 different fixes)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I think Probelm 1 takes place because when the selecting dialogue is showing the pointer reactives handleMouseMoved() and sets itself with the flag"WIDGET_HILITED". After that thenew dialogue comes to the top layer and cuts down the interaction between mouse and Add_Game btn.
Can you give me some functions/params which can prevents situations like this or I just need to disable the button?
Last edit: zhe13 2016-03-31
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I don't think disabling the button is the right approach, as the new dialog that's drawn on top already "greys out" all of the background. This would also require you to enable all the buttons again when the dialog gets focus.
I'll have a look and report back.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
handleMouseMoved() isn't relevant for buttons. I think you mean handleMouseEntered. And it's not the issue. It's not called after the new dialog appears (You can verify it by adding a debug print in ButtonWidget's handleMouseEntered implementation.
I figured out the problem (#1) by adding some debug prints and playing around with the buttons. I will describe the process:
I added warning() prints inside Dialog::runModal() and Widget::updateState() (right where the WIDGET_HILITED flag is set).
Then I tried clicking on a button and seeing what happens. WIDGET_HILITED triggered after runModal. OK, that's what I expected.
Then I tried pressing on a button, moving outside it, moving back to the button, and releasing the press. I noticed the problem didn't occur. The button didn't try to highlight.
So, the problem is that when a button is pressed, a PRESSED flag is set in addition to the HILITED flag. When a button is unpressed, the PRESSED flag is unset, but the HILITED flag is untouched.
The solution is to unset WIDGET_HILITED inside ButtonWidget::setPressedState().
Do you want to submit a fix?
I'll edit this bug to just be about problem #1. Will file a new bug about problem #2.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
summary: GUI: Buttons get wrong highlight when they are enabled/disabled --> GUI: Pressed button keeps highlight after modal dialog opens
Description has changed:
Diff:
--- old+++ new@@ -5,8 +5,4 @@1) Launch ScummVM.
2) Choose "Add Game..."
-**Problem 1**: The "Add Game" file browser will show up. The background dialog will be dark, but the "Add Game" button will be highlighted. It shouldn't be.--3) Hover over the (disabled) "About" button in the background. Press "ESC" close the "Add Game" file browser. to go back to the main window.--**Problem 2**: The "About" button will not be highlighted until the mouse cursor is moved. It should highlight as soon as the "Add Game" dialog is closed (also,due to the earlier problem, the "Add Game" button will be highlighted until the mouse is moved)+The "Add Game" file browser will show up. The background dialog will be dark, but the "Add Game" button will be highlighted. It shouldn't be.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello, Sorry for late.
I am zhe13 from github and busy with my homework these days.
I think it is a problem that the button did not call the changePressedAnimation function immediately after sending msgs.
We can rewire the button class and add a callback function.
Another conditoin is that the pressed value was wrong. I will check it after my courses this afternoon.
See you soon~
BTW, how to change the avatar. This is my ex-girlfriend and I do not want to see her anymore :)
You can change you avatar at https://www.gravatar.com/ (which you have used in the past if you have an avatar associated with your email).
I'll wait for you to investigate the bug before looking into it myself :)
Please also specifically mention if you're tackling problem 1, problem 2, or both (I'm not sure how related they are - maybe it should be 2 different fixes)
Emm I am tackling problem1 and I think it must be related to #7083 .
I think Probelm 1 takes place because when the selecting dialogue is showing the pointer reactives handleMouseMoved() and sets itself with the flag"WIDGET_HILITED". After that thenew dialogue comes to the top layer and cuts down the interaction between mouse and Add_Game btn.
Can you give me some functions/params which can prevents situations like this or I just need to disable the button?
Last edit: zhe13 2016-03-31
I don't think disabling the button is the right approach, as the new dialog that's drawn on top already "greys out" all of the background. This would also require you to enable all the buttons again when the dialog gets focus.
I'll have a look and report back.
I will keep tracking this issue and try to find out a proper solution.
handleMouseMoved() isn't relevant for buttons. I think you meanhandleMouseEntered. And it's not the issue. It's not called after the new dialog appears (You can verify it by adding a debug print inButtonWidget'shandleMouseEnteredimplementation.I figured out the problem (#1) by adding some debug prints and playing around with the buttons. I will describe the process:
warning()prints insideDialog::runModal()andWidget::updateState()(right where theWIDGET_HILITEDflag is set).WIDGET_HILITEDtriggered afterrunModal. OK, that's what I expected.So, the problem is that when a button is pressed, a
PRESSEDflag is set in addition to theHILITEDflag. When a button is unpressed, thePRESSEDflag is unset, but theHILITEDflag is untouched.The solution is to unset
WIDGET_HILITEDinsideButtonWidget::setPressedState().Do you want to submit a fix?
I'll edit this bug to just be about problem #1. Will file a new bug about problem #2.
Diff:
Done. The new bug is #7101.
Diff:
Fixed by 92b7a86e1f9529c78f62a241aee161eb69ff08ab