Groups keyboard shortcuts have been updated
Dismiss
See shortcuts

Blockly default toolbox setup as in demos hard to find

43 views
Skip to first unread message

Bart Zuidgeest

unread,
Jan 6, 2025, 11:42:40 AMJan 6
to Blockly

Hello,

Today I tried adding blockly to my application. From the demos I get that blockly has a nice default generator for several languages. It's a nice starting point.

However I was very confused that in the getting started and other documentation I can find basically nothing on how to set these generators up.

I only discovered I could import the blocks with
import {blocks} from 'blockly/blocks'
by searching github....

I still don't see a default toolbox that includes all these items.

I'm having an easier time adding just custom blocks and toolbox items then adding what I think should be the most basic starting point...

Am I missing something?



Ronald Bourret

unread,
Jan 6, 2025, 12:51:10 PMJan 6
to blo...@googlegroups.com
Hi, Bart,

For information about how to use the code generators, see Code generation -- just import the generator and call workspaceToCode. (When you read this topic, skip the section about block-code generators. That only applies when you are creating custom blocks and is separate from your application generating and running code.) How you execute the generated code is up to you. If you are generating/running JavaScript, see also Generating and Running JavaScript.

Because each application is different, there is no default toolbox. I assume what you are referring to is the toolbox in the Blockly Playground, which is defined in blockly-samples/plugins/dev-tools/src/toolboxCategories.js. If you want to add your own blocks to this toolbox, it's probably easiest to cut/paste this code and then add your own categories/blocks as needed.

Ronald Bourret
Technical Writer (Provided by Synergis)


--
You received this message because you are subscribed to the Google Groups "Blockly" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blockly+u...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/blockly/fa337e34-7912-4484-a767-0d5d3d0fef6bn%40googlegroups.com.

Bart Zuidgeest

unread,
Jan 7, 2025, 2:19:04 PMJan 7
to Blockly
Hi,

I think you might have misunderstood the question.

There is a "default" set of blocks  in the core lib at "https://github.com/google/blockly/blob/develop/blocks/blocks.ts" to be used with the included generators.

Expecting that the number of blocks in that set might change over time, I expected there to be a maintained matching toolbox definition set, maintained somewhere else in the code. But for the moment I only find post of people sharing segments of more or less complete manually created toolbox items based on those blocks. That seems inefficient.

I appreciate that most application will use a custom block/toolbox set. I have even already created one for myself in the past using custom toolbox/blocks and generator combo. But in this attempt I actually want to generate javascript so starting from whats included seemed like an easy start. And as you provide such a nice set of blocks to start with, I expected there to be a officially maintained toolbox set to match it. The "starterkit" if you will :). Using such would also mean that when new block come along I'll be certain to notice.

I can you the list from the example you pointed to. That is certainly helpful and likely to be at least somewhat maintained.

Christopher Allen

unread,
Jan 8, 2025, 9:09:05 AMJan 8
to blo...@googlegroups.com
Hi Bart,

There is a "default" set of blocks  in the core lib at "https://github.com/google/blockly/blob/develop/blocks/blocks.ts" to be used with the included generators.

Expecting that the number of blocks in that set might change over time, I expected there to be a maintained matching toolbox definition set, maintained somewhere else in the code.

I think I must also not be understanding you, because it appeared to me that Ron had already pointed you at exactly such a matching toolbox definition: the one at blockly-samples/plugins/dev-tools/src/toolboxCategories.js.

Can you explain how what you are hoping for differs from this?


Christopher
 

Bart Zuidgeest

unread,
Jan 13, 2025, 4:37:40 AMJan 13
to Blockly
Simply put, if the default block definitions are in the core library, I expect the toolbox set matching it to also be in the core library, not in the sample projects.
The goal of the sample might change and thus it's selection of tools. Many samples have different selections based on their goal. If the toolbox definition is in core besides the default blocks it gets much more "status" and might get better maintenance or such.

I also think that if both are in core then they can be noted in the documentation as available and when you download the library you get both without going to hunt for the "missing" part in the samples. The way I see it, the default generators and blocks are in core and the toolbox to use them is in samples.... Meaning the library is "incomplete". When googling I found a surprising number of post asking for a toolbox listing with answer al being more and less complete. So I can hardly be the only one that would like a default toolbox included with the blocks and generators.

Maybe I'm overthinking this. But that is how I see it. You did all that work, and one has to find the parts of the result in different places making it easy to miss things you put work in. That's a shame.

Christopher Allen

unread,
Jan 13, 2025, 6:26:03 AMJan 13
to blo...@googlegroups.com
Hi Bart,

Simply put, if the default block definitions are in the core library, I expect the toolbox set matching it to also be in the core library, not in the sample projects.

Most probably you will get your wish, but (like with any tricksy movie genie) perhaps not quite in the way you want: although we are planning to move the plugins into the blockly repository, it's also fairly likely that we will follow that up by removing the library blocks from the blockly package and turning them into plugins (as we have already done with some previously-core block definitions like the colour and angle picker blocks).  (In fact, it's possible we may move everything out of the blockly package, leaving it as a wrapper package that merely pulls in (say) @block/core, @blockly/blocks, @blockly/javascript-generator, etc.; this would make it easier for advanced developers to pick and choose which bits of Blockly to include in their apps while still providing a convenient "batteries included" option for those starting out.)
 
The goal of the sample might change and thus it's selection of tools. Many samples have different selections based on their goal. If the toolbox definition is in core besides the default blocks it gets much more "status" and might get better maintenance or such.

Ah hah, I see that the arguably poor naming of blockly-samples repository has caused confusion, because in fact the repository does not contain just samples but also plugins, and, as part of plugins, quite a lot of our dev tooling too.  The blockly-samples repo is as much a part of the Blockly project as blockly project itself, and in fact at present we are able to publish any updates to the plugin packages it contains much more often (automatically, every week) than we are for the main blockly package (typically not more than once or twice per quarter, and sometimes much less often than that).

I also think that if both are in core then they can be noted in the documentation as available and when you download the library you get both without going to hunt for the "missing" part in the samples. The way I see it, the default generators and blocks are in core and the toolbox to use them is in samples.... Meaning the library is "incomplete". When googling I found a surprising number of post asking for a toolbox listing with answer al being more and less complete. So I can hardly be the only one that would like a default toolbox included with the blocks and generators.

I agree that our documentation could be better, and I think we should improve it.  Can I invite you to file a documentation bug with your suggestions about where this information should be included, how it should be worded, etc.?  It would be very useful to know where in our documentation you had gone looking for this information, because that's probably where we should put it!

Maybe I'm overthinking this. But that is how I see it. You did all that work, and one has to find the parts of the result in different places making it easy to miss things you put work in. That's a shame.

Thanks for sharing your perspective and experiences. 


Best wishes,

Christopher
 
Reply all
Reply to author
Forward
0 new messages