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?
This should give a better user experience, since the user will not have to
scroll back to where he was when he used the dialog last.
Thanks to wjp for suggesting this.
This allows opening the dialog on (nearly) the same page again as when it was
closed. Sadly due to the different number of entries in the save and load
version this is not always exactly the same page as before. Same goes for
resolution changes.
Thanks to wjp for suggesting this.
