I've been living under a rock for the past couple of months, not paying attention to the updates of Snap! that much, but I had an idea. Say you had a menu, that needs to be dynamic, like the ones in Snap! that update depending on the amount of objects/costumes.
What if, you added the ability for a set of blocks to be ran that would output a list that Snap! would use to generate the
MenuMorph that the dropdown menu (such as the one shown below) would show?
Might sound a bit complicated, but it's just an idea.
Yeah, that'd be nice. One technical issue is that a bug in your custom menu code could result in an infinite loop in the UI. So we'd have to make sure you can escape from that.
Meanwhile, there's a custom menu feature built into the ASK AND WAIT block, and a library to help you construct custom menus.
Couldn't you do it something like how generic when blocks throw an error when the condition takes too long?
I like this! Instead of using the mettaprogramming features to set a menu on multiple blocks (this is usally very laggy) this would be a nice alternitive
Oh, sure, I didn't mean to suggest that this is an unsolvable problem. Just that implementing it isn't quite like falling off a log. And we need a Snap! API for one input slot interrogating another input slot.
I was thinking of something that would end with a report block, but it would output something that you would see in the normal block editor menu
but it would output a string of text that you would see in this
Yes, that's a possible interface, although I'd prefer that it output a list rather than a text string. :~)
Perhaps you could use the "Menus" library as a base.
Yes, I agree, it'd be nice to have one API for menus rather than two different ones.
could we have @jens thoughts on this?
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.