This fixes bug #14404.
The rercusive call was introduced with commit 325260f that changed
the implementation of Widget::handleMouseWheel to call handleMouseWheel
on the widget boss. If the widget boss is a dialog, its implementation
is to call handleMouseWheel on the widget under the cursor. And
we can end up with an infinite loop.
As indicated in bug #13106, which was fixed by commit 325260f, a
similar infinite loop when using the mouse wheel to scroll tabs in
the options dialog was caused by the commit and quickly fixed. But
the fix was only for that particular case. Here the fix should
be more global.
GroupedListWidget and GridWidget can save what groups they have
collapsed to the config file and reload them. "launcher.cpp" uses those
functions to persist those collapsed groups through
- changing how the games are grouped by
- going from list to grid mode and vice versa
- quitting scummvm and starting it again
textviewer.cpp:84:64: warning: format '%ld' expects argument of type 'long int', but argument 2 has type 'int64' {aka 'long long int'} [-Wformat=]
84 | warning("TextViewerDialog::loadFile(): File size is: %ld", stream->size());
| ~~^ ~~~~~~~~~~~~~~
| | |
| long int int64 {aka long long int}
| %lld
- remove Options widgets of the old wizard;
- add CloudConnectionWizard dialog;
- remove old widgets and add new ones in the layouts;
- update local webserver to allow passing a callback that needs to be called if storage was connected via /connect_cloud.
The resize() function has the option to do the scaling, but
adding it to the construtor avoids having to then call resize().
Also this makes more explicit that by default the sizes are not
scaled. The reason for not scaling by default is because values
with get from the ThemeEngine are already scaled.
This reverts commit 04f040af which forced a bitmap reloading to prevent
reusing already up/downscaled images in case that _scaleFactor has
changed.
However after commit ad31dfc this no longer applies as changing the
scale factor in GUI forces a ThemeEngine destroy and recreate. So
_bitmaps[filename] is safe to keep its cached image which is reused e.g.
during initial theme loading.
It is hacky at the moment, being hardcoded, but I had a dilemma between
hardcoding it for a special case, or introducing yet-another OSystem
API call that will be used only by single platform.
Also, I am struggling with coming up for a proper name for this API.
