I wish this 12 new categories for Snap! 7.0: 
New Categories for the Snap! 7.0:
1.Text to Speech
2.Voice Recognition
3.Files
4.Internet
5.Translate
6.Cognitive Services
7.Weather
8.Sprites and Clones
9.Developer Blocks (only in developer mode)
New Categories, but are from a principal categories:
10.Events, is Control but in a separated categories.
11.Lists, is Variables but in a separated categories.
12.Strings, is Operators but in separated categories.
Why do you need to separate strings from the rest of the operators blocks? How nitpicky can you be?
All of these can be implemented with javascript, and definitely aren't important enough to be their own categories.
These show up separately from the primitives while in dev mode already, so there would be no need to create a whole category for them.
Ok, but this new categories are important to tell the new programmers to program much better with this categories. 
Most of these would be better for libraries than categories, as there'd only be a few utility blocks for each one.
This would not better your programming at all. Programming skill isn't based on how good the language is, it's based on how well you understand the language and how much you've practiced.
i'm starting to think you haven't read any of my original post
Most of the things you're suggesting are already available in libraries. And some of them would really be tiny categories, one or two blocks. Take text to speech, first on your list; the existing text to speech library has two blocks, SPEAK and SPEAK AND WAIT, like the sounds blocks.
Splitting events from control is something we're considering, and separating lists from variables is something we'll definitely do at some point.
Yes but the text to speech API that most browsers support allows one to choose the voice (often several for the same language/dialect). And if a particular browser doesn't have the specified "accent" (wrongly named since often that voice can speak that language in addition to speaking English with an accent) then it uses the default voice - no way to ask what voices are available.
Also one may want to have a hat for when speech finishes. Also there should be block for stopping speech. And the stop sign doesn't stop the speech.
Thank you!!!
I think it would be better if it is "Triggers", but that's my opinion.
I could have sworn I answered this!
The stop sign not stopping speech sounds to me like a bug, not like something we need more blocks for. The STOP ALL SOUNDS block should stop speech, too. This may mean that the library needs to change some existing procedures in Snap! itself. The library blocks do have an input for the language. I'm not sure if the browser will tell us what accents/voices/languages are available. But if so, that would be a good addition to the library.
Probably better if Snap! triggers events that library authors can "listen" to. Redefining things like ide.stopAllScripts is a kludge that mostly works. But easy to get wrong, introduce unwanted dependencies, and will cause problems if more than one library is extending the same Snap! function.
stop-all-sounds and stop-all-scripts come to mind as new events but there are probably many more.
But that means that for every new library on a new topic, we need to change Snap! itself, which kind of discourages new libraries by anyone other than Jens.
How so? The JavaScript of the library functions can add the event listeners. The whole idea is to avoid "chang[ing] some existing procedures in Snap! itself".
But what does the triggering?
What I was suggesting is that the Snap! procedures stopAllScripts and stopAllSounds (and more?) be modified to trigger JavaScript events so library authors can respond to them.
Then each library author would no longer need to modify those functions.
Yes, that would solve your immediate use case. What I was trying to say was that the next library writer might want a signal about something other than StopAllWhatever, and we'd have to modify Snap! to send that signal too.
I suggest someone familiar with the codebase produce a list - my guess is that it would be very small. pauseAllScripts and resumeAllScipts are the only additional ones I know of. But note that all of these are about Snap! events that influence an ongoing activity. Maybe someday playing video will be added.
making it "Triggers" will confuse everyone (especially those coming from scratch).
The "triggers" I'm suggesting are at the browser DOM level - not Snap/Scratch. See triggering JavaScript events. This is only of use to those who use JavaScript to define blocks - e.g. the text-to-speech blocks that inspired this thread.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.