If the current UndoState doesn't modify the "saved state" (e.g. there
is a sequence of undoes/redoes that doesn't modify the saved version
of the sprite compared to the current one), we can indicate that we
are in the saved state anyway (!Doc::isModified).
Some extra changes introduced:
* DocUndo & CmdTransaction were simplified: removing the saved
counter, and storing a specific UndoState pointing to the state that
matches the version in the disk
* DocUndo::onDeleteUndoState() can generate a
impossibleToBackToSavedState() if the saved state is deleted. This
might fix some bugs where a "save changes" dialog weren't displayed
after undoing and making changes (probably related to #3542, but not
sure)
Some extra work is needed to avoid showing the "save changes" dialog
if we are close to the saved state and only non-modification undo
states separate us from there. E.g. if we open a file, select the
canvas, and close it, Aseprite now shows the "save changes" dialog,
this wasn't true in previous versions.
So now we can have access to Skia SkPaint instance directly from
Aseprite UI code (and set the shader, and other properties that are
not yet well-wrapped in laf-os).
We've simplified ui::CheckeredDrawMode with
ui::set_checkered_paint_mode() function, as now the checkered
background shader is stored in ui::Paint (SkPaint) instead of
ui::Graphics state.
In this way we can export each grid cell/tile as an individual sprite,
and use the extrude option on each grid cell. We've added the
--split-grid CLI option too.
Now we can export one (or several) tilesets in one sprite sheet (using
the same options that are available in the Export Sprite Sheet dialog,
e.g. like extruding tiles, related to #1982 in some way).
Some changes:
* New "Source" field and fromTilesets param for ExportSpriteSheet
command
* New ExportTileset command (which acts like ExportSpriteSheet but
with fromTilesets=true by default)
* Added --export-tileset CLI option
m_undoHistory is not valid for tabs other than sprites. For example
opening the README or Home tab does not initialize the undo history,
thus aseprite will segfault when it tries to get its first entry.
Implemented using a new FileAbstractImage interface to get scanlines
for each frame automatically resized (without modifying the original
sprite/without using SpriteSize command/adding new undo information).
Related to #3008
With this patch we fixed some use cases:
* We can show the ui with a default filename { filename=..., ui=true }
* We can specify fromFrame/toFrame for SaveFileCopyAs
Instead of storing a Command* we can store the command ID, which it's
less problematic in extreme cases where the Command that is being
referenced is deleted or recreated, i.e. when a plugin is
disabled/re-enabled.
Several performance issues fixed (as we avoid keeping a ListBox with
ListItem in sync with the UndoHistory/UndoStates). There is still some
room for improvement: e.g. grouping several ui::View::updateView() in
just one if several onAddUndoState() will be called (e.g. when we are
running a script without transactions).
This makes possible to return true or false after the execution of
each command app.command.CommandName() if it successes or fails.
Currently the Lua API documentation says something about this here:
https://github.com/aseprite/api/blob/main/api/command/ReplaceColor.md#replacecolor
But this is not true, the function always returned nil. Now it will
return true or false.
Now we can change several values (zoom, brush size, etc.) pressing a
keyboard shortcuts and dragging the mouse in a specific vector
direction (DragVector). It allows the modification of one, two, or
even more parameters at the same time (e.g. X axis to change the brush
size, Y axis the alpha value of the ink).
This was done to avoid some nullptr references using
SkinTheme::instance() (mainly from
StatusBar::IndicatorsGeneration::add()) when the application is being
closed because an exception was thrown. This might be useful to detect
certain kind of crashes from Sentry.
Incomplete version of the Lua debugger.
Some available features:
* Break in next executed instruction
* Step in, over, out
* See & navigate stacktrace
* See local variables
Some missing features:
* Breakpoints
* Eval user expressions with local variables
The UX needs some improvement yet.
Made Change Color: Increment/Decrement Foreground/Background methods cyclic instead of clamped. At last palette element, incrementing selected color returns to first element. At first palette element, decrementing color returns to last element.
This should improve the mouse movement, where a new mouse cursor was
created on each mouse movement with black & white pixels. It's a
regression introduced in ef4f691459
(which was originally introduced to improve the mouse movement
perception in a 100Hz monitor).
This might be a possible fix for:
https://github.com/aseprite/aseprite/issues/2713
Some features from the beta branch of aseprite & laf were backported
to the main branch of aseprite.
Related commits:
- New memory handling (db4504e816)
- New get event with timeout (e6ec13cc31)
- Convert os::NativeCursor to an enum (06a5b4f3ae)
- Adapt code to the new os::Display -> os::Window refactor (5d31314cdb)
- Save/load main window layout correctly and limit to current workarea (d6acb9e20f)
- Redraw window immediately on "live resizing" (d0b39ebade)
The original intention was to save selected colors in the Replace
Color dialog so then showing up it again would restore those saved
color. But it never worked in that way and just by mistake it was
using the Foreground/Background pair of colors by default (which is
the desidered behavior now). So we are just removing the buggy code
that never worked. (Related to #2028 in some way.)
Before this commit, Octree wasn't support alpha channel.
Also the automatic quantization algorithm selection was removed because Octree support alpha channel now.
For the default theme it makes sense (and maybe for most theme
variants it will make sense to avoid adjusting the screen
scaling). But maybe other themes will want to adjust the scale
automatically when choosing the variant.
We've changed a restriction for tilesets: grid's in doc::Tileset must
have origin=(0,0); and the origin of a doc::Grid only makes sense for
the sprite grid (where the origin is set by the user) or for a tilemap
cel (where the origin is the cel origin).
