This fixes the ASSERT((mnemonic & kMnemonicModifiersMask) == 0) in
Widget::setMnemonic() function, but as a future task we should try to
process/convert unicode chars like 'Ú' as a simplified form,
i.e. pressing 'u' should match 'ú' for mnemonics.
As we've moved all the translations to the strings
repo (06a852d1d4d53e8ebfbb200bce2c2d9f9a2212bc), to facilitate the
i18n work now we load translations from "data/strings" and from
"data/strings.git" folders, where "strings.git" is a clone of the
strings repo (https://github.com/aseprite/strings.git) in
"build/bin/data/strings.git".
This clone is executed automatically in the cmake configuration stage
so it's transparent for the developer and the result is like having
the translations available in the same "aseprite" repo.
Without this when the playback cue is on the highest frame in "PlayAll"
mode it doesn't take into account the direction of the current tag that
is being played and assumes the end of the animation was reached
This is due zlib returning Z_OK (instead of Z_STREAM_END) after
inflate() when all the output buffer was filled (avail_out = 0) but it
reports like there is still available uncompressed data (avail_in > 0).
It makes no sense but an extra inflate() call with avail_out=0
consumes the whole avail_in and the expected Z_STREAM_END is finally
reported.
Without this an exception in DelayedMouseMove::commitMouseMove() could
produce (e.g.) the crash in #3818. This same error handling was
already done for Editor::onProcessMessage() in
DocView::onProcessMessage() to avoid crashing due unhandled exceptions
in Editor message processing.
Regression introduced with 8722c8ec16ab68a69616f1e80362f170f9640494
and d3562b140ce12267693675f3f1f722a2670774ec.
Our re-entrant RWLock implementation is tricky because it doesn't
support to unlock in different order than it was locked.
E.g. If we create a DocWriter (e.g. paste command), and try to create
a DocReader (e.g. PixelsMovement) inside the DocWriter scope, the
reader will return a LockResult::Reentrant, but if we unlock the
write, then the reader cannot be used to upgradeToWrite() because the
lock will have just 0 locks (the re-entrant one didn't modify the
count of the RWLock). This is because it was thought that the
DocReader was going to be unlocked before the writer lock (in the
exact inverse order).
Basically these re-entrant RWLocks will not work fine if we mix up the
order of locks/unlocks in the same thread.
With re-entrant RWLocks we can try to lock the document on each
transaction/command/modification. This fixes several problems running
scripts that weren't locking the sprite in an app.transaction() call.
This already fixes a lot of possible problems that can happen when a
script is running and modifying some part of a sprite that is being
backed up in a background thread.
We still need some work to being able to lock a sprite two or more
times in the same thread to write it. E.g. an app.transaction() should
lock the sprite for write access, but the script transaction function
could call a command, and that command could use a ContextWriter to
lock the sprite again. At the moment this is not possible because we
need a re-entrant RWLock implementation.
Given error:
Could not parse translation base file: File contains no section
headers. file: '<???>', line: 10 'display_name = English\n'
It looks like a known issue: https://github.com/WeblateOrg/weblate/issues/9702
Without this fix a recovering thread could get stuck in an infinite loop when reading the slices of a sprite created with a doc format version lesser than 2.
This fixes a problem where the smaller brush size of the dynamics was
used for tools like line/rectangle/etc. where the dynamics option
aren't used.
We've added some comments for a possible future #4186 too,
implementing dynamics for the contour tool (which is freehand, but the
result is filled).
