A holiday gift from Blockly: new beta releases!

[Aaron Dodson]

Hi all,

As the year draws to a close, we've been hard at work on some new versions of Blockly. There are two new betas available: 11.2.0-beta.2, and 12.0.0-beta.0. If you're interested in testing either or both, we'd very much appreciate it!

11.2.0-beta.2 (GitHub/NPM)
This release has a variety of non-breaking features and fixits. If you're already using Blockly 11, this should require nothing more than upgrading the package with npm. We're hoping to officially release this around December 11; if you find any bugs or experience problems upgrading, please let us know!

12.0.0-beta.0 (GitHub/NPM)
This release represents the next major version of Blockly, and as such includes some breaking changes. It also includes some cool new features, most notably the ability to add arbitrary types of items to flyouts (not just blocks/labels/buttons!) and the ability to use custom variable model classes, which can be handy if you need to add additional fields or metadata to variables. There are a variety of smaller changes to improve extensibility/customization, many of which were driven by work to upgrade Scratch to use the latest version of Blockly. As with 11.2.0-beta.2, reports of any bugs or other problems you experience with this release are very much appreciated. We hope to officially release v12 in Q1 of 2025.

Thank you
Blockly is a community effort, and the core team is thankful for all of you on the forums. We'd also like to express an especially big thanks to Mark Friedman, who has answered an incredible number of forum questions of late, and to the following GitHub users, all of whom made their first code contribution to Blockly in one of these releases. If you've considered filing issues, opening PRs or releasing a third-party Blockly plugin, please take this as encouragement to do so. We don't bite, and are happy to help new (and long-time!) contributors share their work with everyone else.

@Abhinav-Chdhary
@AbhinavKRN
@Adityajaiswal03
@Apocalypse96
@Arun-cn
@BenHenning
@ChaitanyaYeole02
@CodeMaverick2
@Nirmalkumar6112
@Shreshthaaa
@Skye967
@UtkershBasnet
@abhinavjha0239
@aishwaryavenkatesan
@changminbark
@dakshkanaujia
@devesh-2002
@dianaPrahoveanu-SL
@ga-fleury
@ishon19
@krishchvn
@mateusslezinsky
@nullHawk
@omwagh28
@ruthwikchikoti
@shashwatpathak98
@surajguduru
@vexora-0
@winnchen

On behalf of the Blockly core team,
- Aaron

[Clément Contet]

Hi !

Regarding 11.2.0, I have a small regression concerning block comments.

Now it seems that all block comments are resizable and have a default size.

But if I set a large comment text on a block (with setCommentText), the comment view is now too small to show the full text, and the user has to scroll or resize the comment to view the rest.

It is a bit annoying for the tutorial in my app where everything is comment based :(

Is there a way to set the size of the comment view manually, or make the comments non resizable like before?

Kind regards,

Clément

[Aaron Dodson]

Hi Clément,

Thanks for the feedback! You can indeed set the comment size programmatically:

const size = new Blockly.utils.Size(200, 200);

block.getIcon(Blockly.icons.IconType.COMMENT)?.setBubbleSize(size);

Let me know if that doesn't work for your usecase or if you run into any other issues!

- Aaron

[Clément Contet]

Thanks Aaron, it still doesn't match the previous behaviour where the comment size was exactly adapted to the text.

But if there is no other way, I think I can live with it!

[Clément Contet]

Hi, I found out that using warning texts instead of comment texts work for me (well, except for the warning icon): warning texts seem to use the former behaviour (the warning size is computed according to the warning text).

Can I use that safely, or maybe warning texts will be refactored in the future to match the comment texts behaviour?

Thanks,

Clément

[Clément Contet]

Hi again :)
I think I finally understand a bit better: with 11.2, all comment bubbles are TextInputBubble, even if the workspace (and thus the comment) is read-only.

Whereas in 11.1, comment bubbles in read-only workspaces were TextBubble (like alert bubbles).

Is it on purpose?

[Aaron Dodson]

Hi,

Yes, that's exactly right. This was intentional so that the appearance of comments doesn't vary drastically based on the read-only status of the workspace, and also to allow comment text to be selectable/copyable in read-only mode. The TextBubble also gets extremely long for text without line breaks. We don't intend to get rid of TextBubble for warnings, and as you note that keeps the same sizing-to-the-text behavior. If the warning functionality mostly works well for you, you may want to create a custom icon (perhaps subclassing the warning icon, or just a minimal implementation that uses TextBubble) and use that. Please feel free to let me know if you have any other questions!

- Aaron

[Clément Contet]

Hi Aaron, indeed, subclassing WarningIcon was the way to go!

Thanks again,

Clément