Let’s port snapblocks to snap
- render primitives
- render custom blocks
- snap block style
- scratch block styles
it’s kind of hard to understand exactly what you mean by “port snapblocks to snap”, could you clarify?
Maybe he means “recreate a snapblocks renderer in snap”?
that’s what i thought too, but why..?
You are in Snap! if you were to do that. So, for Snap! blocks, you should try to recreate Snap!'s block renderer, not snapblocks.
doesn’t the library “(EDC) Script Pic Costumes” do this?
yes, it does, but it accepts ({move (10) steps} @> as an input instead of
move (10) steps
so? use “code to blocks to code”. if you want that exact format, write your own parser, and use, perhaps, “join input list” (drag list into zero-slot join). if, flying spaghetti monster forbid, you want flat design, use the “getters and setters” library, which rightfully requires javascript
the point of snapblocks is the
.
snapblocks → snap != snap → snapblocks
you can already parse snap to snapblocks, and the title of the topic is the opposite.
why “join input list”? you use it to join scripts with inputs, not turn scripts to text. I’m curious what that is supposed to do.
you are really channeling your inner jens 
(snap developer)
but I don’t understand what flat design has to do with this topic.
That would be an amazing project if someone can do it. I might even adapt it to make it part of snapblocks.
I read it as snapblocks to snap. Why would they bring up join input list if they would be splitting by blocks? Plus, writing a custom parser is much more likely to be parsing text, not splitting snap scripts and analyzing them.
They’re saying if you want to render snap blocks in flat design, you can use the getters and setters library to turn it on. Which I think is pretty relevant.
… until you find out that the latest version of the SciSnap library has those blocks w/o javascript!
PS: Just for clarity, I do agree with the fact that most of those options should require JS, as well as with most of the rest of your post. In defense of @sathvikrias, they aren’t the ones who made this topic - they were just pointing out the difference between what this topic was about and the EDC library.
Snapblocks can render Snap flat design - naturally people in this topic might want that as well.
PPS: The EDC library won’t be able to do things you can’t do in Snap but can in Snapblocks, like this: block {sub-block::looks}::motion.
hehehehe
shhh…
I was mostly unclear as to what the join block would help with.
yes same, but it seemed like they were trying to parse snap code data into snapblocks.
I still don’t understand why you need it in the first place.
If you’re converting snapblocks to snap scripts in snap (without xml editing), then you need to use join to create the scripts.
they’re trying to create a renderer.