Snapblocks (Part 2)

I'm talking about multiline comments. The \n one only works for blocks and not comments.

Well, sometimes it's easier to read it if it's not \n, although I would still support it.

i just found this and thought it was much interesting. piglatin lego batman does it again!
however, when i go to the snapblocks page to test it,
this is what i get:


anyone knows what might be going on??
for some reason the height for the SVG is being set to NaN.

EDIT: this might be a firefox-specific issue maybe...?

Probably, since I'm testing on chrome (brave), not firefox. I guess I should start testing it out on firefox then.

Also, can you see if the dev version works?

yeah, still broken i'm afraid
EDIT: a friend who uses firefox also tested and it was working... so either this must be related to an extension, or the fork of firefox that I'm using (Floorp)
but I still can't quite figure out

my firefox also works

disabled all extensions... none of them were really interferring. very odd
i should probably add that i'm on linux right now, but even then doesn't make much sense... because the regular scratch blocks (not snap) demo page works.
EDIT: here's how the SVG is like on inspect element + the console output.


I think it might be something to do with getting the height of text. While I was trying to get snapblocks to work in nodejs (without a browser), I ran into an issue with the method I used to get the font height of text on a canvas wasn't implemented (just to be clear, getting the width worked, so it's not that the canvas wasn't implemented). Here's the function that may be the cause TextMetrics: fontBoundingBoxDescent property - Web APIs | MDN

Can you show the console from the dev site? It's just that shows references to the source code instead of the minified javascript (it has source maps).

seems maybe less useful...? but here:


I mean, it's better, but honestly it doesn't actually help very much. Can you see if this property is supported by your browser (as in, can you get it from the console, not looking at a compatibility chart) TextMetrics: fontBoundingBoxDescent property - Web APIs | MDN?

this is what I get:


seems that it also probably shouldn't be showing "undefined" either.

Just like I thought.

The reason scratchblocks works just fine, is because it doesn't have to check the font height, whereas snapblocks has multiline blocks, and you can change the font size (with $text-scale).

Alright, it should be fixed here.

It took us long enough to notice this, but

The minus block uses the minus symbol (−), not the hyphen. 8722 is the decimal codepoint of the minus symbol.

But snapblocks isn't aware of that yet.

PNG image
PNG image

Yes, I know, it's fixed in the dev version (I found out when I created my snap to snapblocks converter).

it's working now, indeed

may i suggest a style option for, say... turbowarp? (which perhaps should just be called "3.0 plus" or simply incorporated into the 3.0 style as additional options)
the difference from regular 3.0 would simply be having the ability to change the block shapes slightly (i.e. heights and roundness) and the option to have less rounded input fields for strings/any type fields differentiating it from numbers. just thought it'd be interesting, especially when multi-line blocks look way too tall in 3.0 style. i know snap is the main focus, i just like how 3.0 generally looks, even more so with a few tweaks.

While I personally think that the additions that scratch addons added are better than vanilla scratch, that is not the goal of snapblocks (or scratchblocks). Snapblocks is for converting text to snap / scratch block images, no matter if the source material looks good or not.

Also, the reason the multiline blocks look too tall, is because I have to give space between the lines in order to keep it looking good. Believe me, I have already tried it without the space, and it did not look like scratch 3.0.

I finally got around to adding local blocks.

local :: motion local

{local block :: control local} :: define+

local block
forever {
  local block
}

snapblocks (64)

And no, this isn't just using the @location icon that I added, it's literally drawing it (almost) exactly how snap draws it (which isn't by using the symbol).

Man, I'm so glad I didn't remove the local icon offset calculations from the block drawing script (I literally just set it to 0 before, so I could literally just set that variable to the correct value if the block is local in order to get the right offset).

Yeah now THIS is the true Snap! Language /j
image

I finally allowed the green flag icon to be in text inputs.

broadcast [[__shout__go__] V] @addInput

snapblocks (65)

By the way, the syntax mirrors what snap reports when splitting by blocks.

This also only for the green flag, no other icons can be put into inputs.