All my old blocks with group inputs say that they’re still grouped inputs when I look at the definition, but they behave the same as normal variadic blocks. The value that gets fed into the definition is a 1d list, not a 2d table, and I can only expand 1 at a time or 3 at a time w/ shift clicking rather than how groups work. Even when I re-make the group, the glitch still occurs. The commonality between these glitches is that they are x: (number) ; y (number) slots. I didn’t think it was that big of a deal, but it means that my project is broken.
Could you provide a project link? Thanks.
the last input is the ‘group’ one
I think this is slightly intentional. In v11, the behavior for input groups with the max slots set to the length of the group input was changed to be “option” inputs.
@ego-lay_atman-bay is right. The assumption was that if you had a group whose maximum was equal to the number of items in the group, these are optional inputs. However, in your case the two inputs are optional but should remain together.
To get the old behaviour, you can do this (make sure to change the variadic input from a group to a normal number variadic input or you won’t be able to select “pos” in the dropdown, even though it will work; this has been fixed in dev):
In dev, you don’t even need block variables:
is there a downside to doing set slot [pos V] to (list [100] [100] @<> after the expand signal block?
anyway, I don’t understand the upside to removing the group function when
. What is an “option” input?
Optional inputs. That is, something like this:
If you want to change the fill, why should you have to expand all the way to centered and clear?
Not that I’m aware of. It could be a problem if you wanted to do something like make a block be able to expand to 1 and then jump to 3, because you’d have to deal with existing input values potentially being blocks, but I can’t imagine that coming up in a real scenario.
thank you.
If you want to change the fill, why should you have to expand all the way to centered and clear?
OTOH, if you want to change the clear, why should you have to skip over FILL and CENTERED? :~P Keyword inputs FTW!
sorry, I don’t really understand what this means. Are you suggesting to have one variadic slot per attribute?
This is one of my ongoing disagreements with Jens. I think that we are still missing a feature, that the model of variadic inputs doesn’t really suit this use case. Out in the grownup world, you can use positional inputs (what we have) or you can use keyword inputs. I think this is also what you are trying to invent, by having an input group in which the first sub-input is a menu of keywords, and the second sub-input is the corresponding value. So you’d be able to say
except that the arrowheads would be something different, maybe unfilled triangles
◁⋮▷
like this? (ik it’s ugly, and I removed the block definition, but please still try it)
No, you’re still making the options positional inputs. And the keywords aren’t even visible after you use them:
Which is CENTERED and which is CLEAR? What I want is
You can provide sub-inputs in any order, and the ones you don’t provide don’t look missing and don’t take up space. I’m imagining a use case in which there might be a dozen optional inputs and nobody would use all of them in any particular invocation.
This is probably achievable with existing metaprogramming features, but painfully. I want a user-usable notation, e.g., an OPTIONS radio button at the bottom of the long form input dialog into which you put a table like this:
(the third column is default values) and inside the Block Editor prototype you see three input names
but in the palette the user sees
you can do that in dev 
(working on it now)
Oh sorry you answered while I was editing what I said…
but… this is exactly what we are doing in the new (experimental, under heavy development) microworlds we’re currently working on….
again, please let me work on my open-source project in peace, without screaming about it and annoying me with petty stuff like this. We’ll let you know when it’s ready for you. At this time, the dev version is far from reaching public beta.
At this time, the dev version is far from reaching public beta.
Even from Brian alpha! Unless I’m forgetting something…
yes, what’s happening in dev is basically a string of breathless, wild, super urgent POC experiments that totally change (and break) large parts of Snap! on a weekly - or even daily - basis, none of which might even make it to beta eventually. Or, perhaps even all will eventually make it, but probably not in their current form. That said, I can’t wait to discuss those wild experiments when we’re together in Olot!
What about all inputs defined old way but some marked as hidden/optional. And down arrow with menu to show/hide some.