Block appearance in forums should resemble Scratch 3.0 block styles

[benjiwheeler]

@tjvr and others, we would like to update the scratchblocks code used on the forums to show the pseudo-blocks there.

(I didn't think this was the same issue that's discussed at https://github.com/scratchblocks/scratchblocks/issues/272 , because that seems to be focused on generating the .sb3 format, rather than just html/css)

In this discussion: https://github.com/LLK/scratch-www/issues/2726 , user @nitrocipher provides a fork of scratchblocks that does seem to work.

[tjvr]

Hello! 👋 I didn't know whether you're planning to maintain the forums going forward, which is why I didn't reach out before.

You're right this is a separate issue 🙂

I've added a brand-new renderer to scratchblocks, which renders blocks in the Scratch 3.0 style. The work required to get it onto the forums is just:

• update the scratchblocks and translation JS files
• slightly change the method call to render the blocks.

I'm not sure what to do about the "scratchblocks menu" just above the post editor, I imagine that will need updating to but I don't know if it's still a priority for you. I can probably take some time to look into it if so.

How would you like to proceed? Would you like me to send you a PR? 🙂

_{Sent with GitHawk}

[benjiwheeler]

Thanks for the response, @tjvr!

Ideally, we could just drop in a built js file where we currently use the existing scratchblocks.js.

What's the translation js file? (Sorry, I'm new to this project!)

How does the method call need to change?

Which repository were you thinking of sending a PR to? The problem is that the change on our end needs to happen in the scratchr2 legacy codebase, which is private.

I also don't totally get the relationship between the scratchblocks editor, and the scratchblocks js file (which takes the text syntax and makes it into recognizable blocks). But I assume if that still works, and old forum code is handled by the new code, we should be able to make the switch painlessly.

How does that sound?

[benjiwheeler]

Also, you should know that @NitroCipher did a bunch of great work on their fork, https://github.com/s3blocks/s3blocks . Any chance you could take a look, and work on integrating the ideas you've used?

[ZenithRogue]

The scratchblocks.js file is the compiled version of all of the scratchblocks repository. Blocks.js, style.js, and the others are all packed into that.

[ZenithRogue]

Tjvr and I are on pretty good terms, and he definitely has the more feature-packed engine. If you just want to replace the one file, you can use s3blocks to accomplish the same task for the short term.

[ZenithRogue]

My build on the gh-pages site is the fully compiled version of s3blocks, equivalent to the scratchblocks.js file, albeit a different file name

[tjvr]

I'm aware of @NitroCipher's fork, is there anything in particular you think that scratchblocks is missing? 🙂

A very long time ago I sent a PR to llk/s2forums, which is how scratchblocks got into the forums in the first place. I've updated it a couple of times since then, but the last time my PR was merged into a private repository, since I think the public one is no longer kept up-to-date.

There are a few scratchblocks files in the forums:

• scratchblocks.js
• translations.js
• a small amount of inline JS to invoke the renderer
• the post editor menu

The first two can easily be updated, npm run build in this repository should give you new versions.

Because scratchblocks now has two renderers (Scratch 2 and Scratch 3), the interface has changed a little: we'll need to update the inline JS to specify the correct renderer.

I don't know whether the block editor menu will still work; if nothing else, it'll need to use the new renderer interface too.

The release notes give a very brief description of the new interface; I can write the required changes in more detail, or send a PR to s2forums for you to inspect (with no expectation of it being merged!). https://github.com/scratchblocks/scratchblocks/releases/tag/v3.3

_{Sent with GitHawk}

[benjiwheeler]

Since scratchblocks has been used until now, my preference is for continuing to use a file built from it, so there's a clear place for people to continue to work on it.

I don't think we need to put something in place immediately, though of course, the sooner the better.

I'm more concerned with making sure there is clarity on what we're pointing to, so that we're not feeling like we have to do a lot of comparing and clarifying in the future.

This seems like a good time to get the work in one place.

[ZenithRogue]

The only thing that is missing from the 3.0 version that is breaking a bunch of block representations is the lack of the ring block in the renderer. I personally am using the same block shape as the rectangular drop downs to make it work. I will find an example in a moment

[ZenithRogue]

In scratchblocks:

In s3blocks:

Rings like the one above cause the engine to break ATM in the 3.0 format

when gf clicked
set [variable v] to ({
move (10) steps
turn ccw (15) degrees
etc... ::grey
}::ring)

[benjiwheeler]

@tjvr, do you have a js file that's ready to be dropped in on our end?

[ZenithRogue]

@benjiwheeler My properly built build file is here: https://s3blocks.github.io/js/s3blocks.min.js

[tjvr]

@benjiwheeler Sorry for the delay, busy week at work! I'll try and have a look this weekend, and see if it looks like the new version will work on the forums 🙂

_{Sent with GitHawk}

[tjvr]

Okay, I've double-checked how the forums are currently using scratchblocks, and it looks like you should be able to drop in the latest version of scratchblocks without any issues :tada:

Here's all you need to do:

1. Clone this repository, and run npm run build
2. Take the build/scratchblocks.min.js file, and replace the djangobb_forum/scratchblocks/scratchblocks.js file you're currently using
3. Take the build/translations.js file, and replace the djangobb_forum/scratchblocks2/translations.js file you're currently using
4. Add the style: "scratch3" option to both of your calls to renderMatching().
5. Tweak the CSS:

   .scratchblocks {
     zoom: 0.675;
   }
   .markItUp .scratchblocks-button ul a {
     padding: 0;
     height: auto;
     margin: 0 0 -12px;
   }
   

That should do it! :blush:

[ZenithRogue]

This still isn't functional (rings holding stacks of blocks)

https://scratchblocks.github.io/#?style=scratch3&script=when%20gf%20clickedset%20[variable%20v]%20to%20({move%20(10)%20stepsturn%20ccw%20(15)%20degreesetc...%20%3A%3Agrey}%3A%3Aring)

https://s3blocks.github.io/#when%20gf%20clickedset%20[variable%20v]%20to%20({move%20(10)%20stepsturn%20ccw%20(15)%20degreesetc...%20%3A%3Agrey}%3A%3Aring)

[tjvr]

I'm not particularly worried about rings, since they aren't supported in Scratch. (They're a Snap!-only feature, as you know.)

But to resolve your concern, I've just published 3553ae0, which will make sure we can at least render these somehow :)

[tjvr]

@benjiwheeler Let me know if you need any further help getting this to work on the forums! 🙂

_{Sent with GitHawk}

[benjiwheeler]

@tvjr Thanks. It's a bit of a show process to test this on our end, but we're making progress bit by bit.

[benjiwheeler]

So, I've tried both @NitroCipher's build and @tjvr's build, and both seem to have the same basic problem: the HTML parsing and js/css rendering take a very long time.

I made a simple thread with the content:

[scratchblocks]

when clicked
say [thanks!] for (2) secs
stop this script

define awesome
say [ketchup04] for (2) secs
set instrument to ( v)

[/scratchblocks]

When I view this with the current, Scratch-2.0-style state of the forums code, the page fully renders and is ready for viewing (with pseudo-block images) in an average of 4 seconds.

With @NitroCipher's implementation of 3.0 style, the same page takes 29s to load and render.

With @tjvr's it's better, but still 18s.

It's surprising that the loading and rendering take so much longer. Could this be the result of the method being used to find strings to replace? Or of the method of rendering the 3.0-style blocks?

[tjvr]

Curious. Do you have an example forum thread that you see this on?

_{Sent with GitHawk}

[benjiwheeler]

I was seeing it essentially on all of them. E.g.:

https://scratch.mit.edu/discuss/topic/66790/

My current theory is that it was interaction with a browser extension.

[benjiwheeler]

@tjvr, I'm going to go ahead and use @NitroCipher's version because it seems more ready to go. They are both very similar, and I'm not trying to pick sides. I may be able to revisit which library source we're using after a while.

[ZenithRogue]

Any ETA on when it goes up?

[tjvr]

That's frustrating—I've always hoped to avoid the project forking—but ultimately it's up to you.

_{Sent with GitHawk}

[tjvr]

To expand on my comment in the other thread:

It looks different because I've updated the blocks to match Scratch 3.0. slightly_smiling_face

Simply updating the list of blocks defined in the menu.js file should fix the problem. If you need, I can try and find time to write a little patch; it shouldn't take long at all.

The reason that the menu isn't working right is that I've updated the category of the music blocks, to reflect the changes made in Scratch 3.0. For example, the change tempo by () block has changed from purple to green. In s3blocks, the music blocks still have the old colour. I've also put a lot of work into getting the layout and typography as close to Scratch 3.0 as possible (the aim is to be pixel-perfect) :slightly_smiling_face:

The following patch to menu.js should do the trick, updating it for Scratch 3:

@@ -85,18 +85,18 @@ var blocks = [
   ["doPlaySoundAndWait", "pop"],
   ["stopAllSounds"],
   "",
+  ["changeVolumeBy:", -10],
+  ["setVolumeTo:", 100],
+  ["volume"],
+
   ["playDrum", 1, 0.25],
   ["rest:elapsed:from:", 0.25],
   "",
   ["noteOn:duration:elapsed:from:", 60, 0.5],
   ["instrument:", 1],
   "",
-  ["changeVolumeBy:", -10],
-  ["setVolumeTo:", 100],
-  ["volume"],
-  "",
   ["changeTempoBy:", 20],
-  ["setTempoTo:", 60],
+  //["setTempoTo:", 60],
   ["tempo"],
 
   ["clearPenTrails"],
@@ -158,10 +158,6 @@ var blocks = [
   "",
   ["soundLevel"],
   "",
-  ["senseVideoMotion", "motion", "Stage"],
-  ["setVideoState", "on"],
-  ["setVideoTransparency", 50],
-  "",
   ["timer"],
   ["timerReset"],
   "",
@@ -171,6 +167,10 @@ var blocks = [
   ["timestamp"],
   ["getUserName"],
 
+  ["senseVideoMotion", "motion", "Stage"],
+  ["setVideoState", "on"],
+  ["setVideoTransparency", 50],
+
   ["+", "", ""],
   ["-", "", ""],
   ["*", "", ""],

[benjiwheeler]

Sorry, there seem to be a few remaining bugs in both implementations, and we still aren't rolling out either.

@tjvr and @NitroCipher, we noticed that in both of your implementations, the compose menu includes a bunch of "Undefined" values:

(screenshot from @tvjr's implementation:)

(screenshot from @NitroCipher's implementation:)

[benjiwheeler]

(BTW I fixed the z-index issue that's visible in the screenshot from @tjvr's code above, FYI -- don't worry about that)

[benjiwheeler]

Edit:

I tried and failed to repro a bug I thought I saw, where if you make a forum post with a block like “go to x () y: ()”, and don’t put values inside the parentheses, the block renders without the corresponding input - and turns red. If you put a space inside the parens, the input renders fine.

Again, I failed to repro this bug, so I think it's safe to ignore it.

[ZenithRogue]

@benjiwheeler I'm not seeing on either scratchblocks or s3blocks. Screenshot?

[benjiwheeler]

@NitroCipher Weird, you're right, I can't reproduce it either. I could've sworn I saw that happen! Sorry, that report was mistaken, I guess. I'll make a note in my comment above, sorry for the false alarm