As we wanted the current cel as the first cel to transform (to avoid
re-transforming it with inner cmds when we drop pixels), if this cel
was a linked from other one it will not be removed from the
getEditableCels() list, so two linked cels would appear two times in
the list. Now we remove the current cel correctly when it's a linked
cel after re-adding it.
Reported here: https://community.aseprite.org/t/8618
When we clicked the current cel/frame/layer on MovingPixelsState in
the Timeline, we weren't dropping the pixels, so the range was
different in the Timeline UI, but we were using the old site range
which was different (bigger) than the Timeline range.
Fixes several bugs: https://community.aseprite.org/t/8618
When eyedropper was used to pick tiles from a composed image having an
image layer and a tilemap layer without cels, it tried to pick tiles
from the image layer.
Before this fix a console error appeared during a setTransparentIndex
or setPalette execution (or other functions in the ColorBar class)
while some selected portion of the image was
transformed (MovingPixelsState).
Bug reported: https://community.aseprite.org/t/5288
Without this fix we'll see the selection stroke feedback in the same
level as the active layer. With this patch the preview is displayed at
the top just as in the main branch.
In some special cases (several key press enqueued?) we can receive a
BeforeCommandExecution signal when we are not part of the Editor state
stack anymore.
Related to 5ba8cecdde
This tries to avoid calling onBeforeCommandExecution() after we are
going to the previous state. This might be a problem on all states
that are using a scoped_connection to disconnect from the app::Context
signal in the destructor (instead of in the
onBeforePopState). Something to fix next for all other states.
Original post: https://community.aseprite.org/t/pretty-nasty-bug-specific/8290
Before this fix, if you pressed Cmd Z / Ctrl Z (undo) while moving an image holding Cmd/Ctrl key,
the moved image were gettting stuck on cursor, and console errors were shown on every click.
We've refactored the code to support locating windows (and popups
windows + hot regions) correctly in both modes: with one ui::Display
and with multiple ui::Displays.
For this we've added a new ui::fit_bounds() function that works in
both modes.
In this way we can get pixel from the window surface and put pixels in
the new cursor surface which will represent the crosshair on the
mouse/screen position. In this way we avoid an effect of a slow mouse
response on high refresh rates.
Maybe related to: https://community.aseprite.org/t/3354
