In case there were less items in the list than on a page, it was possible
that a "scrollTo" call scrolled items out of the view even though all could
be displayed. This caused odd behavior in the load dialog in T7G. There
the list contains 10 entries. In case the last one was loaded via the dialog,
the next time it was brought up again it showed the 9th entry at the top
of the view and effectively hiding all the others. It furthermore did not
show the scroll bar because all entries would have fit onto one page.
To prevent this odd behavior, a boundary check has been added to all places
where the scroll position is set. This has been taken from "scrollToCurrent"
which already tried to prevent this.
This fixes the second issue described in bug #3610960
"T7G - savegame glitches".
The credits.pl script now prints both the ASCII and ISO-8859-1 strings
in the credits.dat file when they are different. The About dialog then
chooses either one or the other depending on the current charset
used. This fixes bug #3539986
Now that we actually use the textalign field of Launcher.Version the version
would be left aligned by default. This looks odd for the classic theme and
the low resolution version of the modern theme and is contrary to the old
"default" value, so I decided to center the string explicitly again.
Formerly in LauncherDialog::reflowLayout an incorrect way to query the acutal
text alignment was used for the static text widget used for the ScummVM
version.
This is a manual merge of a slightly adapted pull request #296.
The changes made are:
- Each time the theme format changes, the version was increased
- default.inc has been regenerated in the same commit as the theme changes
To help people familiar with Qsynth (I'm not, but it seems to be
one of the more polished FluidSynth front ends), use the same
presentation and terminology for the FluidSynth settings.
More to follow.
I don't really understand what these parameters do, or what the
sensible values are, so for now the sliders are limited only by
the allowed (or, in one case, "safe") values.
This is consistent with the notification when the widget changes by
clicking. As far as I can tell, that notification was added shortly
before mouse wheel handling was added. It missing from the mouse
wheel handler was presumably just an oversight.
On file-grained sliders, changing the value by one pixel was
unpredictable because it wouldn't change by the same amount every
time. (And of course, some values were not possible to set.)
On course-grained sliders, changing the value by one pixel would
sometimes not change it at all, causing the slider to seem stuck.
Now the slider can be set to any value.
Otherwise, it will look like the value hasn't changed until the
widget is redrawn for other reasons, e.g. by mouse-over.
Incidentally, does anyone know why handleMouseDown() calls
sendCommand() when the selection changes, while handleMouseWheel()
does not?
