GUI: Add mousewheel support to the "Unknown game variant" window

[raziel-]

ScummVM 2.1.0git (Oct 10 2018 08:30:53)
Features compiled in: Vorbis FLAC MP3 RGB zLib MPEG2 Theora AAC FreeType2 JPEG PNG cloud (servers, local)

Once i pick an unknown game there is this window popping up telling me that an unknown game variant has been added and i should report following data to the devs.

This window is already pretty big, but the information in it might be even larger, so a scroll bar was added.
This scroll bar however can only be used by clicking on the "down" arrow.
It would be far more conveniant to be able to scroll it with the mouse wheel, just with any other scroll bar in the GUI/LAUNCHER.

Would that be feasable or even wanted?

AmigaOS4 - PPC - SDL - BE
gcc (adtools build 8.1.0) 8.1.0

[digitall]

@raziel- This would be wanted / intended. I think this was an oversight / not tested for this dialog and the ScrollContainer widget. Fix committed as efcd857083122a669d9ba54d34a4b7aae07c245b.

Closing as Fixed.

[criezy]

This actually was not completely an oversight. I remember playing with this when working on bug #10641 and handling scrolling with the mouse wheel in the ScrollContainerWidget, while working well in the case of the unknown games dialog, was causing a strange behaviour in cases where the container contains other widgets that also use the mouse wheel, such as the options dialog (for example the graphics tab if the ScummVM window is small enough). The issue was that as we scroll the cursor may end up on such a widget and suddenly we are no longer scrolling the container but for example changing the graphics mode. And I was not sure how to handle this properly. Because at the time I was focused on the behaviour in the options dialog (fixing other bugs there) rather than the benefits for the unknown games dialog, I dismissed the idea of trying to get scrolling to work with the mouse wheel.

I think it is a good idea to allow using the mouse wheel to scroll, and I just wanted to indicate the potential impact it might have in other places.

[digitall]

@criezy: Ah... Thanks for the update. I will take a look and see if this is causing issues elsewhere, though I think we will only get a good idea of any critical issues from some user testing feedback from the nightly builds.

If it causes real problems, one solution might be to add a constructor boolean flag to ScrollContainer to enable/disable mouse wheel support i.e. can default to True, but can be set to False for say Options dialog or other tricky usage instances. This doesn't fix the underlying issue, but could allow most usages to benefit from Mouse Wheel support.

I think the main issue is making sure that when you are using the mouse wheel, the scroll or drop-down combo box you are expecting to change _is_ the one receiving events and these are not actioned by unexpected widgets.

[digitall]

OK. I have done some testing of the Options->Graphics tab which uses a ScrollContainer and this does not show any issue with the new code. The mouse wheel moves the Combobox widget when over it and nothing else, and similarly when within the rest of the window with the pointer, the normal scroll is moved for the container. I am going to close this as fixed for now... but it can be reopened or a new issue created if we find any cases where this is causing unexpected behaviour or have any user reports of issues.