ScratchAddons
Rewrite zebra striping addon
Changes this addon to use Blockly.BlockSvg.setColour instead of CSS. This allows addons such as colored context menus and save block image to be compatible with the addon.
@mxmou im using my own lighten function, and since editor-theme3 sets an "a" value for the block colors, my lighten function tries to lighten the "a" value. That causes scratch to error. What do you think is the best way to approach this?
@mxmou im using my own lighten function, and since editor-theme3 sets an "a" value for the block colors, my lighten function tries to lighten the "a" value. That causes scratch to error. What do you think is the best way to approach this?
If it's possible to use the text-color module or tinycolor, that's probably the best solution.
I was wondering if I should use ScratchBlocks.Colours to get the original color of the block if it needs to get un-zebra-striped. Currently, I'm storing the old value of the color in ScratchBlocks.Block. I am not already using ScratchBlocks.Colours because some category names such as events don't align with the category stored in the block (events/event). Even though this addon should never zebra stripe an event block, I just wasn't sure what to do.
I was wondering if I should use
ScratchBlocks.Coloursto get the original color of the block if it needs to get un-zebra-striped. Currently, I'm storing the old value of the color inScratchBlocks.Block. I am not already usingScratchBlocks.Coloursbecause some category names such aseventsdon't align with the category stored in the block (events/event). Even though this addon should never zebra stripe an event block, I just wasn't sure what to do.
Debugger blocks and TurboWarp custom extensions don't use colors from ScratchBlocks.Colours, so I think storing the original color is better.
- Stack blocks inside C-blocks (for example "wait" inside "forever") aren't striped. This might be an intentional change but I don't think it makes sense - they're striped in both Snap_!_ and the current version of this addon.
I intentionally changed that because it felt weird striping stack blocks considering the purpose of this addon.
This just might be me however, I can change it back.
note that is was possible to only create one new property on Blockly.Block instead of two, but I used two for code understandability and readability. its also possible to have two/one "global" variables to achieve the same, like it did before these changes, but this is up to preference.
With the default settings the colours are slightly different
I think the new colors are better - they're more similar to the original category colors, but the difference in brightness is still noticeable enough.
I believe Google/Scratch are working on a new scratch-blocks that would use Blockly as a dependency, instead of being a direct fork. See: https://github.com/gonfunko/scratch-blocks/issues
It's hard to know when that will come into play, but it makes me wonder if it's worth it to use blockly APIs in addons that previously worked fine with CSS.
it is very likely many css addon will have to change as well anyway. either way, for compatibility reasons, it is better for addons to modify blockly.
@TheColaber There's very little point in working on this. Blockly is killing setColour (https://github.com/google/blockly/issues/8280) and recommending using CSS instead.
it is very likely many css addon will have to change as well anyway. either way, for compatibility reasons, it is better for addons to modify blockly.
Well, I think I was right after all.