If we start playing from a tag with a repeat field, we'll just play
the tag as many times it says and continue with the regular animation
of the sprite. Users expect the repeat field to be useful with the
default configuration of the program.
Now the equivalent was "{tag}_{frame1}.png", but it looks like a
regression reported here https://community.aseprite.org/t/17253 were
it was possible to just specify the frame number as in "{tag}_1.png"
This menu was accessible right-clicking the Play button in the
Timeline (and in the Preview window, with specific options for the
Preview).
This change includes some changes:
1. Now if a menu <item> in gui.xml doesn't specify a text field, the
text of the command is used (to avoid double translation, the bad
side is that we don't have a mnemonic specified).
2. Menu::showPopup() can be used with submenus from the root menu, to
do this we have to remove the menu item owner temporarily before we
show the menu as popup (see the change in Menu::showPopup())
3. We can specify a special active DocView for commands with
UIContext::SetTargetView, this is used to set the Preview editor as
active view for commands like TogglePlayOnce, etc.
This "undoing" state (introduced in b43f2a3428)
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 3d7c05c8f1.
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.
