whats a smart script pic
I feel like @ego-lay_atman-bay can find a way to store metadata in exported PNG files.
But an issue that arises if they did that is the switching input types (switching the set pen color input to a ring, then if you export and re-add it, but it does work somehow) and the @addInput (and other) symbols.
It's a script pic that imports the code to Snap! when it's drag and dropped to the window.
oh yeah ive done that b4
Yeah, that's what a smart script pic is. In detail, it's a script image, but with XML data embedded into it. You can do this with normal images, but I wonder if 
will ever have a way to actually read the data. Something like 
would fit.
I don't know about you, but when I'm typing up a block prototype, I see the plusses as something I should type
{+ block + prototype + :: motion} :: define
rather than
{block prototype :: motion} :: define@+
Plus, I feel like more people are going to type the plusses anyway, even if I went with your suggestions. It also adds another layer of complexity, more than snapblocks already adds. The text is supposed to be a direct text representation of the block, which also means that if you type in something, and then snapblocks adds a bunch of stuff you didn't type, it may be a little strange.
I am actually not apposed to the idea of adding something to automatically put in plusses between each segment, as that can speed things up, but I do want to allow the user to also be able to manually type in the plusses.
I actually have plans to generate snap xml from snapblocks, and I do have some ideas on how it could be done.
I think you're not considering that + can be (part of) the name of a block, and that such a meaning-carrying + is very different from the syntactic + for places to add inputs, which is why the former are displayed white and the latter black.
When I see your example block (not the snapblocks version), I read it as "block prototype," not "plus block plus prototype plus." Especially with dark category colors, the white text jumps out at you, and the black plusses are shyer. This was all carefully designed; Jens and I spent an entire year arguing out the details of the user interface (of everything, not just the block editor) before BYOB 3.0 was released.
Maybe you'd prefer the define@plain notation over define@+. That way the default will look like what you're accustomed to seeing.
By the way, the reason we have the plain option altogether is that we clearly want the + version for users' block editor windows, but those of us writing documentation or curriculum want script pics of the plain version, so we can focus the reader's attention on what the block actually looks like when used, rather than on the process of creating the block. If we had black plus signs in the blocks in the palette, then I'd see them more as part of the text of the block -- but we wouldn't have black plus signs in the palette! That would be hideous, and would make it harder for a user to read the text of a block. So we want script pics that look like what's in the palette. That's also why I lean toward making plain the default and requiring @+ for the plus version in Snapblocks: When people put a script in a forum post, they want it to look like the script in the scripting area, most of the time, not like a block editor window.
But, I dunno, maybe I'm wrong about how users think. Anyone else have an opinion?
When I see plain prototype labels, I think Hmm. Why are there no plusses? Weird.
My vote (that is, if I have one) goes to define@plain.
[scratchblocks]
{+ say + costume + ((costume = costume 1)) + :: looks} :: define
say costume [costume 1 v]
[/scratchblocks]
huh
cool concept?
I actually did think about that, I just never said anything. My idea would be for users to use /+ to force that to be part of the block.
Here's ny full idea of what I'm leaning towards.
- It ignores plus signs that are between two block fragments.
- If there are 2 plusses in a row (with a space between), the second one is part of the block. It pretty much alternates for more plusses in a row.
- If there is
\+, it forces that plus to be part of the block. - If there is
@+, it's the special formatted plus that does not count for the block. - If the user does not want to type in any of the plus signs, yet they still want them, they can add the override
define@+, or maybe justdefine+.
I feel like that's the best of both worlds. There's the option for users who didn't read much of the documentation, and an option for users who read all the documentation.
I don't know about anyone else, but I want my block prototypes to look like the block editor, not the palette. I also want my scratchblocks text to look like the block that I'm creating. I feel like that might also be easier to understand for some users, than some special override.
Same.
Huh. Okay, I'm outvoted. I guess I'm getting rusty at thinking like a user. :~)
For @ego-lay_atman-bay:
(the script @addInput {
move (10) steps
} :: reporter operators)
(the script. Input names: ((a)) @delInput @addInput {
move (a) steps
} :: reporter operators)
(the (this script :: control) block @addInput :: ring operators)
(the (b) block. Input names: ((b)) @delInput @addInput :: ring operators)
Can you implement a new ring rounding from Super-Snap!?
Only for "the script %inputNames %c" ring is the normal rounding divided by 3.
Potentially, as I'm currently redoing the snap rendering to use pretty much the exact same drawing functions as snap (just translated to svg). Oh, and I'm fixing the multiline block lines to have consistent spacing.
Alright, I was able to add it.
This is also kind of a sneak peak for my new redone snap style rendering, which you may notice the upvars look much better (and there's less padding in general).
That's so good, I'm giving to you back the developer mode! 
Edit: After all, now the developer mode in Super-Snap! is available.
To be honest, I literally used almost the exact same functions that snap uses to draw the reporters, which means, I was able to just change the rounding value to what super-snap uses.
Super-Snap! is obviously a Snap! mod that gives you more features and old BYOB ones.
That means that old BYOB users can migrate their projects to that Snap! mod. 
Alright, I finally pushed my changes to the snap style. This really does look a whole lot more like snap.
Guess which one is snapblocks (without looking at the filename).
I also used pretty much the exact same functions snap uses to draw the blocks, which really helped make sure reporters and predicates look right.
Just saying, I still want to move these changes to the scratch 2 and 3 styles before a new release, plus I want to add the custom block prototype + formatting.