#7094 closed defect (fixed)
GUI: Pressed button keeps highlight after modal dialog opens
| Reported by: | salty-horse | Owned by: | salty-horse |
|---|---|---|---|
| Priority: | low | Component: | GUI |
| Version: | Keywords: | ||
| Cc: | Game: |
Description
Tested with latest git.
1) Launch ScummVM. 2) Choose "Add Game..."
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.
Ticket imported from: bugs/7094.
Change History (13)
comment:1 by , 9 years ago
comment:2 by , 9 years ago
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).
comment:3 by , 9 years ago
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)
comment:5 by , 9 years ago
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?
comment:6 by , 9 years ago
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.
comment:8 by , 9 years ago
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 insideDialog::runModal()andWidget::updateState()(right where theWIDGET_HILITEDflag is set). - Then I tried clicking on a button and seeing what happens.
WIDGET_HILITEDtriggered afterrunModal. 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.
comment:9 by , 9 years ago
| Summary: | GUI: Buttons get wrong highlight when they are enabled/disabled → GUI: Pressed button keeps highlight after modal dialog opens |
|---|
comment:11 by , 9 years ago
| Owner: | set to |
|---|---|
| Resolution: | → fixed |
| Status: | new → closed |
comment:13 by , 6 years ago
| Component: | → GUI |
|---|
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 :)