I'm working on a tool that embeds Snap to generate working code for a specific language live, as demonstrated in this.
I find it to be very fun to do these kinds of translations, so this feature was right up my alley.
Though there are still things I could say that can be improved (even then I managed to deploy some workarounds with lists, variables and string functions, while still having it update live) and they're the following:
Conditional mapping: I have a command block for variables with a dropdown menu for "increment" or "decrement" (by 1 only), which, set to the variable x would result in x++; or x--; depending on the selected option. This could work by setting on the dropdown options "increment=++" and "decrement=--" but that goes into another suggestion I'll mention later. But essentially, it would just be nice to be able to map code differently depending on set conditions, on how you set up the block. If such a thing already exists I can't say I know how.
...Custom hat blocks: Hear me out, I know that this is Probably one of the most over-requested features at this point that is very much not needed for normal Snap! projects, BUT - it could be used together with the codification features to denote separate events, and to separate code into sections... but mostly for the aesthetic and visuals really.
Command blocks that end a script (like "report"): dunno if this is already a thing, if it is it's probably very hidden, but it'd be useful (well, for learners) for some code that is essentially always at the very end, such as exit;.
Global dropdown menu collections: In the gear icon where you can set dropdown options, set them as read only and other things, you can select some of Snap!/Scratch's own default menu options, like variables, costumes, messages, and the like. I think it would be useful if you could also create menus that always have the same items in them globally, without having to create a separate reporter block just for that.
Option to not expose real value in dropdown menu: as I mentioned previously, I could set the "increment" option to equal to "++" to be able to use it, but that could become a bit visually confusing, so I think an option to have the block continue to say "increment" but it still being equal to "++" would be very appreciated. This could probably be useful even outside of codification.
That's all, I think. thanks in advance to Jens for even implementing this to begin with!
I'm working on a tool that embeds Snap to generate working code for a specific language live, as demonstrated in this.
I find it to be very fun to do these kinds of translations, so this feature was right up my alley.
Though there are still things I could say that can be improved (even then I managed to deploy some workarounds with lists, variables and string functions, while still having it update live) and they're the following:
Conditional mapping: I have a command block for variables with a dropdown menu for "increment" or "decrement" (by 1 only), which, set to the variable x would result in x++; or x--; depending on the selected option. This could work by setting on the dropdown options "increment=++" and "decrement=--" but that goes into another suggestion I'll mention later. But essentially, it would just be nice to be able to map code differently depending on set conditions, on how you set up the block. If such a thing already exists I can't say I know how.
...Custom hat blocks: Hear me out, I know that this is Probably one of the most over-requested features at this point that is very much not needed for normal Snap! projects, BUT - it could be used together with the codification features to denote separate events, and to separate code into sections... but mostly for the aesthetic and visuals really.
Command blocks that end a script (like "report"): dunno if this is already a thing, if it is it's probably very hidden, but it'd be useful (well, for learners) for some code that is essentially always at the very end, such as exit;.
Global dropdown menu collections: In the gear icon where you can set dropdown options, set them as read only and other things, you can select some of Snap!/Scratch's own default menu options, like variables, costumes, messages, and the like. I think it would be useful if you could also create menus that always have the same items in them globally, without having to create a separate reporter block just for that.
Option to not expose real value in dropdown menu: as I mentioned previously, I could set the "increment" option to equal to "++" to be able to use it, but that could become a bit visually confusing, so I think an option to have the block continue to say "increment" but it still being equal to "++" would be very appreciated. This could probably be useful even outside of codification.
That's all, I think. thanks in advance to Jens for even implementing this to begin with!
well thats nice to know but it still doesn't exactly tell me how to make no-tab custom blocks.
either way that is probably the suggestion i care the least about anyway, i'd like to hear thoughts on the other suggestions.
I appreciate your enthusiasm about our work-in-progress wrt codification. As we've mentioned on that page it's a ... work in progress ... and specifically mentions
for the reason that we want to first build a fully working application before we reach out to the community for suggestions and contributions. Snap! is all open, you're invited to check out everything, but please understand that we're not open to community suggestions at this point of development. Thanks!
on a slightly unrelated note since you're here, do you know if i can embed snap into an html page and have javascript extensions work in it? I get CORS policy-related warnings about Access-Control-Allow-Origin HTTP header, though I don't get that when running the page locally.
well of course it does, it is embedding snap into a canvas after all, with some parameters set and a default project loaded. since it's running directly from snap.berkeley.edu it can run the javascript block, and the userscript probably also works because the source is coming from the expected domain.
i tried setting EnableJS from outside with a simple button but it won't do anything I guess, and there's nothing in api.js related to it specifically anyways.
That said if I enable it in the GUI itself with "hideControls" set to false, then I can use it, but I still wanted the controls hidden... or at least some of them.