hi @<:>
cool!
Hi, I have a suggestion for how to group variadic inputs for blocks like the pipe block (and maybe a snapblocks to snap converter, although I don't think that that is necessary). Basically, variadic inputs would be grouped together using quotes like this:
pipe [] @arrowRight "(()@>)
(()@>)
(()@>)" @<:>
or maybe like this (quotes outside of arrowheads):
pipe [] @arrowRight "(()@>)
(()@>)
(()@>) @<:>"
to create this:
(\ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ (()@>) pipe [] @arrowRight (()@>) \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ (()@>) @<:> ::control)
It's a good idea, however I'm not sure how I feel about using quotes. It just doesn't feel natural. I'll have to think about it.
Yeah... All the brackets are taken though... I could list off a dozen different keyboard symbols, but I don't know what would be the best fit.
«» ⟨⟩ ⟪⟫ ❨❩ ❴❵ ⟦⟧【】《》〘〙〔〕 ⦅⦆ ⦇⦈ ⦉⦊ ⦍⦎ ⦑⦒ ⦓⦔ ⸠⸡ ¿? etc. Lots to choose from! 
.. on the standard english qwerty keyboard
you're telling me you dont have left arc less-than bracket on your keyboard? nonsense
I just decided to look into this, and it turns out it's the scratch Japanese translation of the stop [ V] block. Heck, it's even like this in scratch.
Honestly I'm not sure what I want to do about this.
snap should take priority over scratch in snapblocks though...
I just looked at the snap translation and...
Also, I don't actually have any snap translations in snapblocks, because I'm honestly not sure how to go about adding them in.
why uh oh?
Because a block with just a single input is becoming a control cap blocks.
[]
Which is also messing with the define block, which I can fix now that I know what the issue is.
Using firefox. Snapblocks is inaccurate for me (exporting as PNG works fine though):
The actual block:
PNG export:
This doesn't happen in Scratch 2 style, so this is a problem specific to the snap block style.
Can you be more specific about what's "inaccurate"? It's hard for me to know what you're talking about with low resolution screenshots.
From what I see I believe the inaccuracy in question are the shadows.
The block looks "flatter" than usual, even though the images aren't in the flat block style.
I wouldn't spend to much time on it. It is still clear what the block is.
Yeah, I wasn't planning on it, I've already had to compromise a method for getting the inset border for the flat design specifically for firefox.
ha, svg filters. i've gone through a million iterations designing the block rendering for my own project, they just never scale properly.
can't the drop shadow be a regular css filter instead?
filter:drop-shadow(-1px -1px)
as for the other filters, i'm not sure why they're there. snap draws block edges with paths, the gaps are visible when zooming in. i would've expected the edges to be drawn the same way in the svg (even though it looks odd).
