More input options

Feature Requests
1

I know that SNAP! has a lot of options for custom block inputs, but here are some more that I think would be very useful:

  • SNAP! code in an option (drop-down) menu

    • What I mean by this is that currently, if you have a drop-down menu and you want your input to be a Boolean or other non-text input, you have to have many if-then statements for each of the options. If you were able to drop SNAP! code directly into the input, then a menu would be treated no differently from a normal input, it just happens to have pre-made values. For example, let's say you are making a block that generates a random number in a range with some restrictions. Your restrictions are it must be even, odd, prime, or a custom input. When multiple inputs plays nice with other input types, the user can either select one from the list, or drag their own custom condition onto the slot. Inside the block, there are now more if-then statements, the block can, the block can't even tell that a predefined input is actually a thing.

  • Multiple inputs with an option (drop-down) menu

    • This is pretty self-explanatory. You should be able to have a drop-down menu as well as have the multiple inputs boxed selected. For example, let's say you are again making a block that generates a random number in a range with some restrictions. Your restrictions are it must be even, odd, prime, or some combination of them. With multiple inputs selected, as well as a drop-down menu, the user can now select any combination of inputs. Inside the block,because of my first suggestion, the multiple drop-down menu input simply returns a list of statements for the code to use.

Thanks for taking the time to read this. Pleas tell me if any of these suggestions are already possible, or if they would be hard to implement.

tl;dr- I wAnt MoAr InPuT oPtIoNs :crazy_face:

2

We've thought about those things. Another one you didn't mention is a way to group some adjacent inputs and/or title text, and then make the group variadic. The canonical use case is the SWITCH or CASES block, which wants a group of a Boolean input slot and a C-shaped slot, and then be able to have one of those pairs for each alternative. (Now we fake it by having a separate block that takes those two inputs.) But these things, while generally desired, are low on the priority list because we're busy putting out fires about the web site and teacher support.

3

No, its fine, no need to hurry. I was just wondering if this was even a possibility.