Added FILTER_LOOP_THROUGH_ROW_BEGIN/END macros to simplify some
boilerplate code for each filter.
In this way if processing just one row takes too much time, canceling
the operation is faster.
We can use a thread pool (avoid creating/destroying threads) and we
can continue the same task running when the filter restart (there is
no need to stop/wait and restart, because the filter task keeps
calling the applyStep() function anyway).
Several changes were included:
- Fixes in TextBox widget to show it with proper size hint when it's
outside a viewport
- Added the IncompatFileWindow with a message + link to know how to
update Aseprite and solve the situation
- Moved CannotModifyWhenReadOnlyException from app/doc.h to
app/transaction.h
Given 32ed6622d4, now we could be in a
situation where the sprite is loaded without layers because all layers
are incompatible with the current version. So we have to take care of
this situation in the Timeline UI.
With multiple windows on, if a modal/foreground window like Canvas
Size (which has a special onBroadcastMouseMessage()) were running, and
there was a script dialog also opened on the background, the
non-foreground dialog could receive clicks. This patch fixes this
particular scenario (no other window than the actual foreground window
can receive mouse clicks).
In this way we can completely disable the log of data recovery events.
In a future we might offer a way to log all these events in a log file
(probably included in crash reports).
We've received crash reports where save_xml() throws an Exception()
because the user brushes file cannot be saved (open_file(..., "wb")
returns nlulptr). We're not sure why (probably privileges?) but at
least we fixed the exception.
Added properties needed to know where the mouse position is on the
editor canvas + a method to cancel app.editor:askPoint() from Lua.
Related to aseprite/Attachment-System#102
This is the first attempt to finally implement the require() function
on Lua. The main problem was how to solve conflicts between plugins
that use the same library name. Here we separate each plugin like in a
namespace, so require(name) inside a plugin will save the module in
_LOADED["pluginName/libraryName"] to avoid conflicts with other
libraryName from other plugins.
We receive kMouseMoveMessage as the first message of a multiselect
message in a ListBox when the kMouseDownMessage message is received by
a separator first e.g. if we click a separator from the Recover Files
tab and start dragging the mouse this assert was failing.
Before this the ASSERT(group.items.empty()) in
AppMenus::removeMenuGroup() was failing when a plugin created
subgroups/submenus inside groups.
We have to remove plugins items in the reverse order that they were
added to uninstall them correctly.
An empty cel must be counted as a layer for the z-index ordering, so
the z-index refers to number of layers to move back/front, but number
of non-empty cels in the specific frame.
A this fix, a new issue appears: #3820
We can use:
Image:clear()
Image:clear(color)
Image:clear(rectangle)
Image:clear(rectangle, color)
If the color is not specified it will be the transparent color of the
image.
Co-authored-by: David Capello <david@igara.com>
This is necessary to prevent the manager to invalidate a window whose relayout is not finished. This can happen when a script opens a new window when another is currently opening. For instance a script whose canvas.onpaint handler opens another dialog.
In this way we can use F2 to:
1. Set the Loop section if two or more frames are selected
2. Remove the loop section if only one frame is selected
3. Rename the active layer if the layer is selected (or no frames are selected)
* Now a Cel has a z-index property to change the order of layers per frame
* A new doc::RenderPlan class can calculate the order of cels to be rendered
* z-index is saved as a int16_t in the .aseprite files
* This new field can be set/get from Lua with Cel.zIndex
An initial implementation (not yet ready for production) of the
ShaderRenderer to use SkSL shaders to convert indexed -> RGB, and draw
SkImages directly on SkCanvases (this will enable future GPU
acceleration).
The SimpleRenderer outputs unpremultiplied RGB values when we render
in a transparent background, we have to indicate that to Skia now that
we're compositing os::Surfaces (SkiaSurfaces) directly in this
FullscreenPreview command.
Regression introduced cc7da16691 when
the Console was converted to a non-modal window. If a script prints
something, the console is displayed, then the user can close the
console, and if the script tried to print something else the console
window wasn't displayed again until some other command was
executed (any command that called the Console::Console() constructor
which would create the ConsoleWindow again).
With this fix the console window is recreated/displayed again on the
screen.
This bug was well-known (but I think never reported yet) and probably
the possible source of the #3787 issue.
Renderer::renderCheckeredBackground() function was used only for the
FullscreenPreviewCommand, but now we use
ShaderRenderer::renderCheckeredBackground() to render the background
in the Editor too. So the sprite is painted in a backbuffer and then
composited with the already painted background using
Graphics::drawSurface().
This new renderer uses a shader to paint only the checkered
background. It can be tested only in ENABLE_DEVMODE and pressing F1
key to switch between the renderers (which is a devmode special key
for testing purposes only)
We've changed the Renderer::renderSprite(Image*, ...) member function
to renderSprite(os::Surface*, ...) so we receive the os::Surface
directly to paint the SkCanvas with a SkShader. Probably more
refactors will be needed.
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.
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).
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).
As now the BrushType button has an odd number width (15px), it's
better to limit the brush size to an odd number size (9px instead of
10px). In previous versions the BrushType button had an even number
width (16px) so the 10px brush size was correctly centered.
As the "multiple windows" feature is still buggy (#3556) and we've
disabled it by default, it's nice to make this option more visible (in
the General section) so users reliant on this will find the switch
quickly.
It's not safe to listen this event from a script because it can be
called from a background thread. We keep the code for a future
solution (in case that it can be found).
In other case, consider to finally delete this code.
Added a new Dialog{ notitlebar=true } parameter to avoid showing a
title bar explicitly. So we can continue using Dialog() to create
dialogs with the default "Script" title.
Regression introduced in 453d9c2168
Added a Sprite.tileManagementPlugin property for plugins that want to
replace the standard tilemap/tileset interface. This includes a new
external file field in .aseprite files to specify that the sprite
tiles are controlled by a specific plugin.
Once this property is set, the standard tilemap/tileset modes
selectors will disappear and the only way to make then available will
be setting this property to nil/empty string again.
Fix https://github.com/aseprite/Attachment-System/issues/21
We've added an experimental option (enabled by default) to keep the
compressed tileset data when we load/save a .aseprite file to avoid
recompressing each time we save (and only compressing the tileset if
tiles are modified).
This is an attempt to make the save operation faster when we use
sprites with several tilemap layers + large tilesets (many tiles, with
big tiles).
Reference: https://github.com/aseprite/Attachment-System/issues/54
We've tested writing uncompressed tilesets, it's too slow for big
tilesets. Anyway read_raw_image/write_raw_image now support saving
uncompressed tilemaps if necessary in the future.
This can happen when any fatal error happens in
createSaveDocumentOperation(). The function must return nullptr to
stop the operation and avoid the regular saving process. This is
already checked in the GUI, but we have to do the same when the fatal
error happens from the CLI.
We cannot delete a tileset yet from Aseprite UI, but now an extension
can do it through Sprite:deleteTileset(). Deleting the non-last
tileset will create an Tilesets array with an empty (nullptr) slot on
it (so tileset indexes are not changed, and for the future, if some
external file is referencing that tileset index, the reference will be
kept).
Related to https://github.com/aseprite/Attachment-System/issues/19
In this way the store (in memory) the exact timeline position for each
DocView. Useful when editing multiple sprites and the timeline jumps
from one side to another.
Now, if the tileset does not belong to the sprite object, the lua engine throws an error. Also added a warning when tile_index = 0 on Sprite:deleteTile()
Actually it looks like a long-standing bug in the write/read_tileset()
functions where tileset names aren't saved (so another bug fixed with
this change is that restoring a tileset from a crashes session/file,
will restore the tileset name correctly).
This is to simplify code and to match ui::MenuItem::Click and
ui::Button::Click signals (so then we can write some generic code
using Button::Click or MenuItem::Click).
We've refactored the AsepriteExternalFiles struct to make it a
class (hiding members), storing maps ID -> filename per file
type (e.g. so we don't mix external tileset filenames with extensions
names, etc.), and re-using IDs for extensions names with the same
name (there is no need to store the same extension name multiple times
in the external files chunk).
Right now it just creates a plain widget, but now we can specify
hexpand/vexpand arguments too so we can create a canvas with a fixed
size or with dynamic size (e.g. to use the whole dialog client area).
The onpaint event is not functional yet.
There is an issue where we can drag a recent item and load a file
(using Alt+F or Ctrl+O) while dragging the recent item. With this
commit the overlay is destroyed after the file is open (without this
the overlay is kept floating).
Probably related to #3504 but we're not sure.
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.
Before this fix, during the action of selecting an area (with any selection tool), the preview of the selection edge in grayscale Color Mode was not displayed (fix#3274).
Playback is still buggy, and we need to fix some test cases, but this
is useful to fix a crash/assert fail if we try to set as active frame
something outside the valid range.
Before this fix, the string '{duration}' in the file format gave an incorrect/random and constant number across all frames. This happened in Save-AS, Export File, CLI, Json on Export Sprite Sheet.
In this way we can know if the event was generated from a
undo/redo/undo history change and not from the direct user
manipulation of the sprite.
Useful for scripts like in #3539
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.
Before this fix, file and image sizes were calculated incorrectly. This caused problems for some viewers/browsers/engines to load BMPs created in Aseprite.
Prior to this fix, any additional external files or directories within the Extension's directory tree, break the subdirectory removal iteration, resulting in empty subdirectories and a console error.
