Scratch-blocks: Add list blocks, _ of _ sensing block, procedure blocks

[tmickel]

So we can start testing how any block shape changes could impact the blocks.

[tmickel]

For now:

• stub color field with field_number
• stub number/drop-down field with regular field_dropdown
• how to deal with custom blocks?

[IAP-Reloaded]

Custom blocks would probably be best with a dropdown of all their variables.

[tmickel]

@IAP-Reloaded I'm not sure I understand what you mean?

[tmickel]

More colors:

[towerofnix]

Are custom blocks considered part of "more"? What's "text" mean? The color of text in blocks..?

[tmickel]

@liam4 As a note these colors aren't final. Custom blocks are considered part of "more" and "text" does mean text in the blocks (as currently implemented).

[mrjacobbloom]

@liam4 it's the color of text within string/number inputs, not labels

[tmickel]

Thanks to @joaoh1, many blocks are implemented!

Still missing from the set of 2.0 blocks:

Looks:

• [x] switch costume to [costume name]
• [x] next costume
• [x] switch backdrop to [backdrop name]
• [x] go to front
• [x] go back [n] layers
• [x] costume #
• [x] backdrop name

List blocks:

• [x] [list] reporter
• [x] add [think] to [list]
• [x] delete [n] of [list]
• [x] insert [thing] at [n] of [list]
• [x] replace item [n] of [list] with [thing]
• [x] item [n] of [list]
• [x] length of [list]
• [x] [list] contains [thing] ?
• [x] show list [list]
• [x] hide list [list]

Events:

• [x] when this sprite clicked
• [x] when backdrop switches to [backdrop]
• [x] when [loudness] > [n]

Sensing:

• [x] [x] of [y]

Backdrop only:
Looks:

• [x] switch backdrop to [backdrop] and wait
• [x] next backdrop
• [x] backdrop name
• [x] backdrop #

And, custom blocks :)

[nanaian]

It'd be nice if custom blocks had _defaults_, because within Scratch 2.0 at the moment people have to modify the project JSON :package:

[tmickel]

@nanalan Explain more - do you mean default argument values?

[nanaian]

@tmickel Yep! :smile:

[rachel-fenichel]

That falls more under developer tools than under specific blocks. New issue?

@nanalan if you're interested in custom blocks, you should check out Blockly's custom block creation as well: https://developers.google.com/blockly/guides/create-custom-blocks/overview

It's not going to do everything you want, but may be a start.

[nanaian]

@rachel-fenichel I meant that as a request for llk/scratch-blocks, not Blockly, haha. Thanks for the reference though!

[rachel-fenichel]

@nanalan I know, but I'm curious what you think about Blockly's custom block creation--in particular, the block factory. I haven't played with scratch block creation yet.

[mrjacobbloom]

@rachel-fenichel I think I'd prefer something more like Scratch 2.0's block editor. Designing the block in a WYSIWYG editor seems easier than writing code to create each input and label, even if it allows less control over types and things.

[Jonathan50]

Scratch's custom blocks are procedures written in Scratch, Blockly custom blocks (I think) are extensions to Blockly written in JavaScript.

[rachel-fenichel]

Ah right, I thought you were talking about Scratch extension blocks, which I think are equivalent to Blockly custom blocks.

[joaoh1]

i know a way to implement Custom Blocks,
While i wait to Pull Request #501 be merged, i added custom blocks at my website:
joaoh1.github.io/sb-onlinetests

[tmickel]

@joaoh1 I took a quick look at your custom blocks demo. While that's a really interesting idea of how to approach defining blocks, I think we'll probably have to wait to merge anything like that until we can figure out some design and UI issues (and perhaps make something similar to what we have now, with the "make a block" dialog). Thanks for doing the experiment, though - it's great to see things like that.

[joaoh1]

I know a way to implement Lists and Custom Blocks:
By cloning field_variable file and modifying it (To Custom Blocks, Make the creating window convert words like number, boolean and text to inputs)

[nanaian]

@tmickel We'll likely - I've seen discussions already - get a lot of backlash from Scratchers for changing the Custom Blocks colour to _red_, as it makes it seem like a 'broken' block - i.e. some 'hacked' blocks in 2.0 are red to show they aren't supported/known.

It might be worth allowing people to colour their own custom blocks: that'd be fun! :tada:
Obviously if that has its own design flaws, then the purple from 2.0 will probably be the best choice.

Just my two cents.

[towerofnix]

@nanalan On thisandagain's Scratch profile:

They are only red temporarily. We generally make items in the UI that have not been styled yet bright red or bright green to make it clear that they are unfinished.

[tmickel]

@nanalan,
@carljbowman may have comments on that. I think the color is not intended to be red, but "coral" - but I see the similarity. We are also still playing with colors, so may have some (possibly dramatic) tweaks/changes.

[tmickel]

Custom colors is an interesting idea. As you mention it probably has some difficulties (e.g., when you open a project that uses them, it's not as clear what category they'll appear in). But I like the thought :)

[tmickel]

Moving to backlog for the rest - I think we have enough to evaluate and fix shape now.