Command refresh and refactor, ui availability consistency (fix #3025)#5303
Conversation
aseprite-bot
left a comment
There was a problem hiding this comment.
clang-tidy made some suggestions
dacap
left a comment
There was a problem hiding this comment.
I didn't make a full review, but just some comments so far in some changes I was able to see.
Actually Command_call should return false if the command fails (an exception is thrown). Anyway there is not too much information about the error, and for regular errors (non-exceptional, like the UI is not available) we could try to create a new method to return command results (probably related to #3952). I'd leave this error handling for the future (not in this PR). |
5108762 to
b9c8838
Compare
|
Did the changes, I'm also gonna see about documenting the fact that we reuse instances because it can definitely be a gotcha for script authors as well.
An exception yes, but the command being disabled still returns Edit: Added |
I think this internal detail shouldn't be documented in the API. Shouldn't affect the behavior of scripts, at least commands should behave like an action in itself that doesn't depend on previous calls of the same command.
Yeah, we can add a new kind of result code 👍 Anyway we might need some way to check if the command is enabled before executing it, e.g.: if app.command.SaveFile.enabled then
...
end |
|
Added the
|
dacap
left a comment
There was a problem hiding this comment.
I've fully review the PR now, some extra changes 🔍
aseprite-bot
left a comment
There was a problem hiding this comment.
clang-tidy made some suggestions
af637d3 to
f0f9e34
Compare
|
Added parameters for |
aseprite-bot
left a comment
There was a problem hiding this comment.
clang-tidy made some suggestions
aseprite-bot
left a comment
There was a problem hiding this comment.
clang-tidy made some suggestions
f0f9e34 to
2889555
Compare
2889555 to
366751d
Compare
Fixes #3025. Companion PR to api/#124
I've gone through all of the commands testing them in batch and UI mode and this PR is the resulting cleanup which:
falseinonEnabledwhen they will not work in batch mode, instead of failing silently or crashing.uiparameters toLoadMask,LoadPalette,ModifySelection,PaletteSize,SaveMaskandSavePalette.CmdUIOnlyFlagandCmdRecordableFlagflags, which did nothing.Now that
Command::onEnabledis more consistent, I think we should consider adding a way for scripts to know that the command they attempted to execute was disabled by something, and ideally also for a way for commands to report errors. Right now, the command return value doesn't really do much.One way to do this would be adding something like
app.getLastCommandError()or something like that, that we could populate after every execution? Maybe with some common error codes or strings, that way scripts could communicate in their own way what errors they stumble into.