I think a find replace function would be nice to have
You drag blocks into the window and then it replaces all instances of that specific stack with the thing in the second window. If there’s nothing there, it just deletes all blocks in that formation
This would definitely help me. Right now I’m very discouraged from changing already existing systems but with this it would allow me to be more open to changing things
He might mean that or the Snap! Integrated find/replace blocks function
cymplecy have worked on the find block:
I’m not aware of Snap!’s “integrated replace blocks function”. If it exists, it’s apparently undocumented.
No, the only thing along those lines that does exist is that renaming a block will rename all its instances. But as you point out, this is one of many problems that can be solved with metaprogramming, pushing a built in solution down in priority. (I'm personally excited at this vigorous return to our original design philosophy of giving you the tools to solve your specific problem yourself, rather than giving you a special purpose primitive. For all its virtues, media computation has led to a huge number of special purpose primitives about costumes and sounds.)
She*
Yes that’s what I was talking about
I haven’t actually written code for a search & replace function to operate on program blocks (the example I posted was a mere mockup, or vaporware if you like). It appears to me that writing seriously useable code for his purpose is going to be a bit of a challenge.
I agree insofar as limiting the number of primitives is involved. Moreover I feel the Snap! IDE should be more open to user-developed libraries. I may open a separate topic to discuss this, sooner or later (i.e. after some further thinking).
I guess I agree in principle. I'll be interested to see a specific proposal that deals with security concerns.
Will you elaborate on the "security concerns"? I suspect these are related to JavaScript - I have no experience implementing Snap! blocks in JS though, so perhaps you could try to explain how a perpetrator would go about.
Yes, Javascript. You can do more or less anything malicious running unconstrained JS code.
Our current model, which isn't perfect but has worked well for us, is to allow JS access in two different ways. Anyone can use the JS Function block, but every time such a project is loaded, the user has to check the "Javascript extensions" option in Settings 
to allow it to run. This means that if you're running someone else's project you at least get warned that you're trusting the author. It's annoying to authors because they have to check the box every time they debug their project, and we keep getting requests to make checking the box permanent for that user and project, but that would kind of defeat the purpose.
The other way is to be an official blessed library. Then we take your JS code, which we've read, and install it in Snap! itself, accessible via the PRIMITIVE blocks. This means anyone can use your code, not just your own library, but that's okay because we've blessed it as harmless.
This dichotomy leaves out the potential middle, a user-defined library not officially blessed by us. If we had a huge bureaucracy, we could, I guess, bless anyone's library, but in fact we reserve this for major, generally useful libraries such as SciSnap and TuneScope. And we bless them in the sense that they're in the official Libraries list.
Thanks for the explanation.
Having users explicitly check the "JavaScript extensions" box may be OK from a legal point of view (= to prevent litigations against UC Berkeley after a possible security breach), but doesn't much help the average user, who isn't familiar with inspecting underlying JavaScript code - is that at all feasible? - and may still be interested in trying other users' projects / function blocks.
As for a safe “middle ground’’ (user-defined libraries) I envision two (complementary) options:
- Blocks utilizing Snap! primitives only;
- Blocks that do require “JavaScript extensions”, and were scrutinized by independent, trusted & knowledgeable users (whether any user would still need to engage “JavaScript extensions” could eventually be decided by the official moderators, perhaps after some probation time).
Such mechanism would not strictly prevent users from entering inefficiënt / sloppy / crazy / useless code into libraries, but IMO that’s of less, and later, concern.
Exactly that but it would apply to the entire project or just that sprite
Yeah, but then we spend our time blessing users instead of blessing libraries.
Bear in mind that we are seriously not interested in being a front end to Javascript. We're delighted to help people wtite libraries in Snap!, but a JS-based library has to be super useful (e.g., SciSnap) for us to want to encourage it.
What we figure is that users will check the box if they trust the user who made the project. The message should be clearer about this.
Is that real?
Apparently you (@cookieclickerer33) replied one of my posts - which one? (or perhaps it was unintended)
I’m not sure what ”Is that real?” refers to. Please explain, so I (?) can try to answer your question.
Click on the picture that says it was a reply to you, it pulls up what I was replying to
O, yes, I see what you mean now.
It was a mock-up (as I already explained in post 9), meant to get a feel for what you were / are looking for.
Yea it should be possible to make that but it would require some work
Do you know how?