This starts saving files synchronously. So, the progress
isn't lost.

Maniphest: T10784

This had nothing to do with

CCBUG:407381

CCBUG:407381

Differential Revision: https://phabricator.kde.org/D20772

This gives a better UI (not overly large) for screens with scale factor
set to *.5x.

This option is enabled by default. It is currently only available on
Windows.

This adds a series of patches related to QTBUG-53022 [1] for Windows to
allow enabling support for fractional DPI scaling.

These series of patches adds the option
`QGuiApplication::setHighDpiScaleFactorRoundingPolicy` to control how
the DPI scale factor is rounded (or not), which can also be overridden
by the environment variable `QT_SCALE_FACTOR_ROUNDING_POLICY`. The
options include:

- Round: Round up for .5 and above.
- Ceil: Always round up.
- Floor: Always round down.
- RoundPreferFloor: Round up for .75 and above.
- PassThrough: Don't round.

Currently the default option is explicitly set to `Round` to obtain the
old behaviour (where 1.5x is rounded to 2x).

Ref:
- https://bugreports.qt.io/browse/QTBUG-53022
- https://codereview.qt-project.org/157173
- https://codereview.qt-project.org/157174
- https://codereview.qt-project.org/161334
- https://codereview.qt-project.org/163219
- https://codereview.qt-project.org/176381
- https://codereview.qt-project.org/209886

A previous attempt was made in D1977 [1] but it didn't work properly.
The patch `0003-Hack-for-fullscreen-workaround.patch` only partly hid
the issue and the issue has resurfaced since this patch was removed.

This commit actually enables Qt's workaround with an additional patch
from Qt 5.13 [2]. The workaround adds a 1px border around the window. An
additional hack is added to hide three of the borders, though we can't
hide all four borders since the bug will return. This currently leaves
the bottom border visible as a compromise.

This workaround is not active when ANGLE is being used. If anyone is
annoyed by the 1px border, they may consider switching to ANGLE.

[1]: https://phabricator.kde.org/D1977
[2]: https://codereview.qt-project.org/246155

Differential Revision: https://phabricator.kde.org/D20657

1) Fix support for negative offsets
2) The setting is applied right after pressing OK in the
   configuration dialog
3) Qt fetches this updated info after tablet proximity leave/enter
   cycle.

Go to Preferences->Tablet Settings->Wintab->Advanced...

In the dialog one can select between modes:

* Use information provided by tablet ---  we fetch the mapping
  from the tablet driver

* Map to entire virtual screen --- default way how Qt handled it
  before

* Map to custom area --- just map to the custom area of the screen
  in **hardware** (that is, unscaled) pixels.

The patch allows switching of the Tablet API when we use Qt's own
implementation.

The patch is added to our build system, so the fix should appear
in nightlies very soon.

The patch has also been proposed to Qt:
https://codereview.qt-project.org/#/c/258067/

BUG:405494

In the interest of experiment, it's enabled for the daily builds.

We can now log important events to a krita.log file. It is completely
independent of qDebug, and only meant for those actions that we know
users often get wrong or have problems with. Right now, it logs
creating, loading, exporting and saving a file, and switching between
the smoothing options.

The krita.log file is NOT automatically uploaded or shared or anything
like that. The header that explains this is translated so users can
see that for themselves.

We rotate 10 sessions in the log file, so even if the user starts Krita
a few times after having a problem, we should still be able to review
the problematical session.

The logging api is pretty simple: a static KisUsageLogger::log method
that writes a timestamp, and a KisUsageLogger::write method that writes
an informational line without a timestamp.

Note that the logger is created and torn down in the main function:
this means that the location is GenericDataLocation, not AppDataLocation.

CCMAIL:kimageshop@kde.org

You need to add -DHAVE_HDR to enable HDR-related code. But
you will need a patched Qt for that.

The patch also makes the code behave correctly on Linux
systems.

PS:
The patch also makes it possible to select OpenGL ES renderer
on Linux. The renderer is selected fine, but doesn't work for
some reason. I guess some texture format is set incorrectly.

This patch generalizes the thing previously implemented in kis_opengl_win
by Alvin Wong long ago.

The algorithm is based on two finctions: KisOpenGL::selectSurfaceFormat()
and KisOpenGLModeProber::probeFormat(). The former one generates the full
list of all possible renderer/format combinations, then sorts it according
to user's preferences and HDR necessity, then probes every resulting format
with the latter function. As soon as it finds a format that fits the
requirements, it makes this format default for the root surface of the
application.

Notes:
1) It is configured in Settings->Display->Root Surface Format
2) Rec. 2020 surface doesn't fully work because the we cannot do ICC
   conversions with it
3) One needs to restart Krita to get the surface type activated
4) One can also get the properties of the current display in the
   tooltip of the display label in the preferences dialog.

Since 9d95d8d5 fixed the canvas,
there's no reason not to make this the default anymore.

https://lostdomain.org/2017/06/17/qt-qnetworkaccessmanager-causing-latency-spikes-on-wifi/
https://bugreports.qt.io/browse/QTBUG-40332
https://bugreports.qt.io/browse/QTBUG-46015

Now we can run krita 3 and krita 4 side by side, even if the single
application option is enabled.

If we have an override language, Qt doesn't accept that, even though
we set the entire environment correctly. This means we get translated
dialog box buttons, but we cannot do anything about that. This attempts
to at least fix the application layout.

CCBUG:399440

Off by default, this makes it easier to check whether bugs are
caused by our fork of Qt's classes or to check whether Qt's tablet
support has improved.

CCBUG:399379

BUG:396594

Also, on macOS, only set one language; ki18n gets horribly
confused and takes random translations if there's more than
one language set with setLanguages.

BUG:396010

This also adds a safe assert that fires whenever we create a
read/write KisConfig object in a non-gui thread.

As it was, it is unused, and the log docker has its own message handler

And don't check whether there is a supported tablet api in those
cases.

CCBUG:395878

And don't check whether there is a supported tablet api in those
cases.

CCBUG:395878

(cherry picked from commit 94a65412)

For each language in the list, also insert the language with the country
code stripped so that ki18n can load languages that doesn't contain a
country code, e.g. ja_JP vs ja for Japanese.

It handle certain cases where the preferred UI language of a locale is
different from the locale name itself, e.g. zh_HK uses zh_TW as the
preferred UI language.

This change does not affect Linux.