This covers the settings dialog itself and option pages based on
`UiFileBasedOptionPage`. Other option pages need to react to the
new `OptionPageWidget::retranslationRequired()` signal or handle
the `QEvent::LanguageChange` event which is now propageted to the
page's widget.
The web view is only an optional enhancement in my applications so having
the support disabled is rather common. So for a better out-of-the-box
experience when configuring my projects it makes sense not having to
disable web view support explicitly if Qt WebEngine is not installed
anyways.
For some reason the tool button's palette changes back to the old palette
when applying changes. So it cannot be used to hold the intermediately
selected paletted.
The change for avoiding a warning from MSVC about 64-bit shift operations
introduced a different warning from GCC. Hopefully this now avoids warnings
in all compilers.
* Set the default icon theme when applying Qt settings and the "system"
theme is supposed to be used but none could be determined by Qt
* Use a bundled icon theme depending on whether the current palette is
light or dark
* Apply the default not only under Windows anymore; supposedly this makes
sense under any platform where Qt cannot determine the icon theme for us
* Use `qEnvironmentVariable()` to read env variables into `QString`s
* Treat CLI arguments as UTF-8 (they will be converted to UTF-8 on Windows)
which is consistent with the CLI argument handling in tag editor
* Add comment about processing of `m_iconThemeArg` and reserve the correct
size when building the `QStringLiteral`
At least the documentation of `QIcon::setThemeName()` sounds like it could
make a difference:
```
The name should correspond to a directory name in the themeSearchPath() …
```
* Avoid setting platform setting in Qt 6.5 as it is no longer needed for
dark Window frames
* Reference recent blog post
* Add real `isDarkModeEnabled()` function using new Qt 6.5 API (as existing
`isPaletteDark()` function is only based on the current palette)
Martchus