This "undoing" state (introduced in b43f2a34280b64c95a8941bb43ba7b87a77e9c3b)
is used in the scripting AppEvents (a ContextObserver) onActiveSiteChange()
impl to trigger a 'sitechange' event for scripts/plugins so they know
if the change was from a undo or from the regular user interaction
(some scripts will add more actions to the transaction if the change
is from the user, not from a undo/redo, or now with this fix,
navigating the history)
This was a source of crashes for the Attachment System when using the
Undo History (e.g. https://github.com/aseprite/Attachment-System/issues/83
+ using the Undo History window)
In some way we prefer to simplify the GraphicsContext class instead of
exposing a new Paint() class (which might be confusing with the
app.useTool() too).
Now BlendMode can be used for GraphicsContext.blendMode and
Layer.blendMode (not all modes are available in both cases).
This reverts commit 3d7c05c8f1a61fde43039649f8e35dbe7c1124c7.
As creating a new layer was generating a onActiveSiteChange() event,
if a script was listening that event and adding new
actions (e.g. changing the layer properties), the order of cmds was
incorrectly created (e.g. cmd::SetUserDataProperty for the layer, and
then the cmd::AddLayer).
With this change we first add the cmd::AddLayer and then any extra
cmd::SetUserDataProperty (or any other action) that can be added in
the sitechange event.
We've created ev.fromUndo flag to the app 'sitechange' Lua event so
scripts can detect if we are undoing/redoing in a site change event,
and avoid adding new properties/actions when this happens.
And we have added a new exception (CannotModifyWhenUndoingException)
to detect if a new action/cmd is added (incorrectly) when we are
undoing/redoing.
Related to #3720
We were finally able to reproduce #3504 (an assert fail) and it looks
like a bug in the Widget::removeChild() function, where kPaintMessage
messages weren't removed from the queue after the widget is removed
from its parent.
It looks like the std::variant impl doesn't convert from long long to
int64_t type automatically, but we might be wrong. Anyway this patch
does fix this.
We have to copy all missing <style> into the new theme, so these
styles are re-loaded using colors and parts from the new
theme (instead of using the data of the default theme).
We cannot use the fix from 6e2b44c72d811adf87fdfb4731f748266e6a2102 as
they contain different slice borders depending on the state (and that
generated moving labels/icons in RGBA/Grayscale/Indexed buttons when
we hover the mouse on them), so we had to revert it and use a new
"buttonset_item_active" theme part to set the background of Edit
Pal/Tiles.
Now these buttons look more like the previous version, where the
special background color is painted to the edges. To achieve this the
"buttonset_item_normal" part has less border to fill the background
with "edit_pal_face" color in "pal_edit_button_unlock" and
"edit_tiles_mode" styles.
The icon/stylus was inverted. We've also moved the icon for each state
to the theme xml (so we don't need to use setIcon() manually anymore
for this button).
