fromSb3: Fix loading component-based pen color blocks; document shadow blocks' fields more carefully #145
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Development:
Hard-codes(!) a special-case fix for the
pen_menu_colorParam
shadow block; we reviewed all shadow blocks that Leopard supports and would have included like fixes for any similar cases, but this is the only one.pen_menu_colorParam
is different from normal SB3 shadow blocks because its field is namedcolorParam
and does not match the name,COLOR_PARAM
, of the input into which it is placed. All other names do match and we can just apply the shadow block's field as an sb-edit input with the same name, but this one needs to be manually transferred from sb3 fieldcolorParam
to sb-edit inputCOLOR_PARAM
.This fixes loading blocks which use this input (there are two in the Pen extension) and makes it so output formats see the
COLOR_PARAM
input that they're expecting. Our testing:toLeopard
andtoSb3
are working, and don't require any changes.fromSb3
and writes withtoLeopard
,toSb3
, andtoScratchblocks
)project.json
is now pretty-printed w/JSON.stringify
for more convenient git review. The SB3 is very old and saving it from the Scratch editor without making any changes will still produce a flat-out different file (in subtle ways), so the diff was manually reviewed to only commit the code changes. This should make for a clean diff in the snapshot file.