#7083 GUI: Browser's "Go Up" button appears pressed when it's not

[Ori Avtalion]

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.

[rootfather]

I can confirm this bug for ScummVM 1.8.0 on Windows 10.

[Ori Avtalion]

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.

[Ori Avtalion]

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.

[zhe13]

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.

[Ori Avtalion]

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.

[Ori Avtalion]

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?