The name of the ‘Current’ calligraphy profile should now be shown
as translated. It’s also *stored* with the translated name
(i.e. the translation of the string ‘Current’). This doesn’t seem
optimal, but the rest of the existing code seems to depend on this.
And the two other profile names (‘Mouse’ and ‘Graphics Pen’) are
also stored with the translated names (meaning that they don’t
change when/if the translation is changed).

Before, both tooltips were just ‘Height’ (a copy and paste error?).
The new tooltips are based on the descriptions in the reference manual.

In case of conflict in i18n, keep the version of the branch "ours"
To resolve a particular conflict, "git checkout --ours path/to/file.desktop"

We should not use QtCuncurrent anywhere in Krita

Our "empty" devices have a weird extent (qintmax, qintmax, 0, 0),
which makes the LoD generation algorithm crash when it tries to read
from qintmax-tile. So we should just check it.

BUG:408785

Otherwise it won't have text.

BUG:410500

Before: The ‘created’ and ‘updated’ times were stored as datetimes
in the author’s time zone, but *without* a time zone marker. If a
different user had a different time zone, the time displayed would
be wrong (e.g., it could be a datetime in the future). Also, the
format of the displayed time was a strange mix of locale-aware
stuff (e.g. localised month names) and non-locale aware stuff
(the order of the different components in the datetime).

Now: The times are always stored as UTC datetimes, with an explicit
datetime marker (‘Z’). (So no information about the author’s
location is leaked.) They are always shown in the user’s preferred
short datetime format (and in the user’s time zone).

The above is true for ‘created’ and ‘updated’ times stored as
actual datetimes. Older versions of Krita only stored the date,
and in the fixed ‘dd/mm/yyyy’ format. For these bundles, the date
is displayed in the user’s preferred short date (not datetime)
format.

Even better would be to use the mimetype, but that would also
take more time.

This one is in the category: how did this not break sooner, but alas.

The ‘last updated’ time was a datetime, but the ‘created’ time
was just a date, which was parsed as midnight on that date.
Now they’re both datetimes.

The ‘created’ date was set to the ‘last updated’ date,
and the ‘last updated’ date was never set.

BUG:408731

This will allow for the date to be displayed as a localized format.

For bundles using the old format, Krita will convert these appropriately.

Don't register mouse (tablet, touch) actions for the transform stroke
until it is fully initialized.

We should ensure that commands with id < 0 are not merged. Otherwise
transform operations of different origin will be merged, although we
didn't expect it.

Batch markers must not be compressed. I thought that returning a fake
LoD would ensure it, but it is not the case. If we have multiple "start"
(or "end") markers, they should not be compressed as well. For this
purpose, I introduced KisUpdateInfo::canBeCompressed(), which returns
false for all the marker info objects.

The old icon was the ‘Refresh View’ icon, while the new one is
the ‘Mirror Horizontally’ one, which is easier to understand.

The publication time of the news items on Krita’s welcome page is now
shown in the user’s timezone and in their preferred short datetime format.
The timezone of the datetime in the RSS feed is now also taken into account
when parsing the publication date (the old code basically assumed that the
user lived in the timezone the RSS feed generator was set up to use, which
at the time of writing was UTC).

Note that old code only displayed the date; the new code also displays
the time (typically hh:mm).

In case of conflict in i18n, keep the version of the branch "ours"
To resolve a particular conflict, "git checkout --ours path/to/file.desktop"

(and also in multihand brush)

Now the canvas rotation/mirroing code is fully ported to the new
API, by passing via KisPaintInformation instead of paintop settings'
temporary properties.

BUG:404408

Apparently this is possible, and Qt Creator complains about returning
the rect the old-fashioned way...

BUG:410137

deviceSettingDescription can be any type of data.

BUG:410242

All of the colour palettes included in Krita that have unnamed colours,
have actually the colour names set to ‘Untitled’ in the .gpl files,
instead of having empty names (I’m not sure it’s valid to have empty
names, though). So the code that tried to show unnamed colours as the
translation of the string ‘Untitled’, did not succeed. Now, colours with
empty names or the name ‘Untitled’ are treated the same, so that the
i18n() call always succeeds for unnamed colours.