Dynamically populating dropdown input slots

[mr_owlssssnap2]

And also extremely cursed lol

[mr_owlssssnap2]

Hey unrelated, but how do you add a left input arrow in snapblocks?

Who the hell flagged this for off topic, I literally said unrelated because snapblocks doesn't recognize list unless it has @delInput so I wanted to know how to add it

[qw23]

@bh

the ring doesn't have a title text, so you can't include labels for the inputs, as in the GO TO X: () Y: () block …

Not a real issue (IMAO), since you can choose appropriate names for the inputs, like in:

@bh

… and you have to grab a CALL or run block whenever you want to call the helper. I know this is what people these days call a "first world problem” …

… and rightly so

@bh

… in my own Snap*!* programming I find myself avoiding that notation, instead making the helper a separate toplevel procedure with extra inputs to carry over the main procedure's inputs. (In dynamically scoped Logo, you don't need the extra inputs to the helper.) You did the same thing in the streams library, defining hidden toplevel blocks as helpers to a visible block, rather than using internal lambdas.

IIRC this approach provides (or provided) better runtime performance. Don’t know why.

@bh

To say all that in a more abstract way, that notation doesn't feel like block programming, because there's no block you can grab.

Granted.

[ego-lay_atman-bay]

@delInput
@delInput :: other

I also created a guide on how to use snapblocks, which goes over many things: How to write snapblocks

[mr_owlssssnap2]

Thanks! IMO, you should make a symbol just called @addDelInput or something if you haven't already that does both

[sathvikrias]

@ego-lay_atman-bay

@delInput

honestly, i think it would have been better if we could just say @DI @AI, or @DAI as an abbreviation.

Also, 3 new blocks, no idea what they do but im trying to figure it out. (also I think this topic would make more sense in Development because this feature is not done yet)

[mr_owlssssnap2]

@sathvikrias

3 new blocks

set slot [ V] to []::control probably does

@mr_owlssssnap2

To add options, you must append report (list [option1] [option2] @delInput @addInput) to the end

for you

EDIT: No it just automatically sets the content of the input to it, not add an option
Jens and the rest of the Snap programming team are really going crazy with these amazing updates!

[mark4sisb]

[mr_owlssssnap2]

Oooh that's neat

[sathvikrias]

the set slot block can actually be used for non-menu slots!

[mr_owlssssnap2]

oh, that's actually pretty useful!

[tethrarxitet]

I like this. It inspired me to make a simpler version of this here: Snap! ! Backpack 10.2

Brian, I do love the changes here for dynamic menus. I thought it was really interesting with the C+C library. But wouldn't it be confusing to have custom-block-special blocks in the stage? I would recommend adding a new palette to the block dialog so that it would be separated better. If not, a small indication that should be added to the "block blocks" is with the new cube or cubeSolid symbols, like so:

or I could propose a new symbol, $blockManipulator, could look like this:
These changes are really interesting and would definitely attract a few library creators.

[ego-lay_atman-bay]

One idea that I've thought of, is splitting then into a section in the control category, and adding a label text for the section. I know it's possible, since it's used for the lists category, and dev mode blocks.

[bh]

We've been talking about "drawers," a feature in which the section label text would have an arrowhead after it that you'd click to make those blocks appear. The main blocks would always be visible, and the specialist blocks would be hidden but discoverable to keep the palette smallish.

[jens]

I've also been thinking about splitting the Control category, or about introducing one or two new categories, one of which would be "Blocks", and it would contain the rings (from current Operators), all the blocks in the Control palette that have rings (RUN, LAUNCH, CALL, PIPE, TELL, ASK), and then all the metaprogramming ones from WHEN (anything) IS EDITED downwards. Introducing 2 new category buttons would also let us put the "other" blocks into their own palette.

[bh]

@jens

Introducing 2 new category buttons would also let us put the "other" blocks into their own palette.

I vote for splitting Lists from Variables!

[ego-lay_atman-bay]

I agree, since having an empty category (by default) would probably confuse new users (like, "why is there a category with no blocks?").

[bh]

My idea about Other is that we should rename it to Custom and it should include all the custom blocks in addition to them being in the category matching their color. Other would still be a block category; its blocks would be gray and would live only in the Custom palette. Jens doesn't like the idea, though.

[cymplecy]

I'm trying to get the label name of the reporter from within the dynamic menu script without having to explicity drop the block itself - i.e I'd like it to work for any block.

I've tried the usual suspects (caller/script etc) but not having any joy

Is this currently possible?

[jens]

the label of the block instance? That's currently not yet exposed to other scripts except the definition body. But internally it's totally there. But ... where should we draw the line? What's the point of exposing it? You know the label, because you've defined the block, right?