Opened 9 years ago
Closed 4 years ago
#7083 closed defect (outdated)
GUI: Browser's "Go Up" button appears pressed when it's not
| Reported by: | salty-horse | Owned by: | |
|---|---|---|---|
| Priority: | low | Component: | GUI |
| Version: | Keywords: | ||
| Cc: | Game: |
Description
This is a graphical glitch in the GUI.
In the "Add Game" dialog, if you press the "Go Up" button, the button will be drawn as "pressed" as long as the mouse cursor is on it, even when the mouse button is not being pressed.
Ticket imported from: bugs/7083.
Change History (10)
comment:1 by , 9 years ago
comment:2 by , 9 years ago
This also shows up on the "<" ">" arrows of tab widgets (such as in "Edit Game").
I think I have a fix for this, but I'm still trying to make sense of the existing code.
comment:3 by , 9 years ago
I figured out the problem, but fixing it requires some decision-making :)
Theoretically, buttons have an interesting behavior coded in them. When you press and release a mouse button over a GUI button, its "pressed" graphic will persist for a few moments before going back to the "unpressed" state. So the buttons have a stickiness to them.
This is handled through the "tickle" system in the GUI. The button's owning dialog is supposed to call the button's handleTickle() function, which then checks if the timer has elapsed, and it should go back to the "unpressed state".
However, this never happens. The owning dialog only "tickles" buttons that have the flag WIDGET_WANT_TICKLE set. ButtonWidget doesn't have it set. So it waits for someone to call its HandleTickle, so it would "depress" itself, but no-one does. This usually goes unnoticed since most buttons disappear from the screen once they are pressed (with the "Go Up" and "<" ">" buttons being notable exceptions).
To complicate matters, the buttons are sticky in AGI's predictive text entry dialog (PredictiveDialog). That dialog has custom code that calls HandleTickle on the buttons, and ignores whether they have WIDGET_WANT_TICKLE set or not.
So, I'm not sure why the button stickiness feature is even implemented. It makes little sense for cursor-based interfaces where you press down and release presses on your own. Using the predictive text dialog with a mouse feels weird - the buttons feel sluggish. If it's useful for some other backends, maybe just enable it for them.
comment:4 by , 9 years ago
Yep,I think it need a callback fuction to change the paramater immediately. when I add a call for function:stopPressedAnimation after sending the message of button, it does work. However, this way seems so ugly that I prefer to finding another way to fix it. I am tracking the param "pressed" and the best solution will show up soon.
comment:5 by , 9 years ago
Stopping the animation immediately is a roundabout way of disabling the "Sticky button" feature without removing the code that animates it in the first place. I'd rather wait for a decision if that feature is still useful, and if it's not, remove it properly.
Please hold off working on this bug until there's a decision on what to do with the "sticky button" feature.
comment:6 by , 9 years ago
I have received confirmation that the "sticky button" feature can be completely removed, so that's what we're going to do.
zhe13, do you want to tackle this?
comment:7 by , 8 years ago
| Component: | → GUI |
|---|
comment:8 by , 4 years ago
ScummVM 2.2.0git (Jul 15 2020 10:24:49)
Features compiled in: Vorbis FLAC MP3 RGB zLib MPEG2 Theora AAC A/52 FreeType2 FriBiDi JPEG PNG cloud (servers, local)
Is this still an issue?
I can't reproduce this with the above ScummVM version in either "Classic", "Modern" or "Remastered" theme.
AmigaOS4 - PPC - BE - SDL
comment:9 by , 4 years ago
ScummVM uses the native OS "open file" dialog for me. Is the old code gone, or just disabled? In any case, this can be closed.
comment:10 by , 4 years ago
| Resolution: | → outdated |
|---|---|
| Status: | new → closed |
@salty-horse
Thank you for the feedback.
I guess it has been fixed in the meantime.
I can confirm this bug for ScummVM 1.8.0 on Windows 10.