Snapblocks

[ego-lay_atman-bay]

	Summary	Allow users to use snapblocks in their posts.
	Repository Link	GitHub - snap-blocks/snapblocks-discourse: snapblocks discourse plugin · GitHub
	Install Guide	How to install plugins in Discourse

Features

Snapblocks is a fork of scratchblocks that allows users to convert text into images of Snap! scripts. This Discourse plugin allows users to use snapblocks in their posts.

You can create snapblocks in a post, by typing snapblocks code inside [snapblocks][/snapblocks] bbcode tags. For example:

[snapblocks]
move (10) steps
[/snapblocks]

You can alternatively use [scratchblocks][/scratchblocks] as an alias, though it can be disabled.

You can also use [sb][/sb] to add snapblocks code inline.

Use the [sb]move (10) steps[/sb] block to move forward.

Options

There are a few settings available to change how snapblocks are rendered.

• Block Style
• Block Scale
• Zebra Coloring
• Block Wrap
• Show Spaces
• Santa Hats

Many options can also be used in snapblocks snippets.

[snapblocks blockStyle="snap-flat" wrap="true" wrapSize=100 zebra="true" showSpaces="false" santa="true"]
when flag clicked
if <[] = []> {
  forever {
    run ({} @addInput) with inputs [Hello world] @delInput @verticalEllipsis @addInput
  }
}
[/snapblocks]

You can also set the block style using the default parameter.

[snapblocks="snap-flat"]
move (10) steps
[/snapblocks]

Configuration

Name	Description
Block Style	The default block style. Can be snap, snap-flat, scratch2, scratch3, or scratch3-hc.
Block Scale	The default block image scale. Must be a float.
Zebra Coloring	If multiple blocks are the same color, alternate a lighter color.
Block Wrap	Wrap block parts onto a new line if the block gets too wide.
Show Spaces	Show spaces as a dot in inputs.
Scratchblock Alias	Enable the [scratchblocks] alias.

CHANGELOG

• 1.5.0
  • Update snapblocks to v1.10.0
  • Fix error with loading the snapblocks library (it was throwing an error because of a “bad filename”)
• 1.4.1
  • Fix multiline code snippet quoting
  • Actually detect block translations
• 1.4.0
  • Make quoting snapblocks better
  • Text in blocks cannot be selected (though you can still select over them and quote the whole script).
• 1.3.0
  • Add “Santa Hats” option to settings
  • Add santa option to snapblocks snippets
  • Updated snapblocks to 1.8.0
• 1.2.0
  • Allow the [scratchblocks] alias to be toggled (I finally figured out how to do it).
  • Update snapblocks to 1.7.0
• 1.1.1
  • Make sure overflowing scripts can be scrollable.
  • Added actual text when using the snapblocks button in the toolbar.
• 1.1.0
  • Updated snapblocks to 1.6.0
• 1.0.0
  • Initial release

TODO

• Allow separate default style for [scratchblocks]

[thoka (Thomas Kalka)]

Are there any incompatibilities with scratchblocks that would suggest the need for a separate plugin for Scratch?

If not, it could be noted here and in the plugin’s README on GitHub.

[ego-lay_atman-bay]

I’d say that the only incompatibilities are mainly just some minor syntax tweaks, like dropdown menus and the define block. For the most part, scratchblocks code is mostly compatible with snapblocks.

I do still think there should be a separate plugin for scratchblocks, since I know forums that are for scratch/scratch mods might not want to use snapblocks, since snapblocks is geared to work best for snap (and I have been lacking on the scratch styles polish), not to mention, I didn’t add the ability to switch the toolbar shortcut to use scratchblocks instead.

If anyone would like to try and create a scratchblocks plugin using this plugin as a base (I’m probably not going to get around to making one myself), I think it’s worth noting that the render function I used is not in the scratchblocks api, so it would take a bit more work than just dropping in scratchblocks.

[thoka (Thomas Kalka)]

It appears, at first glance, that there is no objection to utilizing this plugin for initial experiments (my environment being a school setting) and only then investing time into a Scratch plugin should the necessity arise.

[thoka (Thomas Kalka)]

Feature request: The block-style could be defined separately for the [scratchblocks] alias.
This would allow effortless usage of different styled Scratch and Snap! elements.

[ego-lay_atman-bay]

That’s actually a good idea. I’ll look into adding that.

[RGJ (Richard - Communiteq)]

I don’t see any server side logic, this could better be built as a theme component?

[ego-lay_atman-bay]

It’s hooking into the message parser in order to make sure nothing inside the tags are parsed, and includes many options for configuring the behavior. I also want to have the new WYSIWYG message composer support, but I’ve been having trouble getting that working well. I also mainly do not want the forum admins to have to enable it for every theme, cause that can cause problems and confusion (I’ve already seen that happen before).

So is there something I’m not understanding with the capabilities of a theme component, and can it just be an enable once globally and forget it type thing?

[RGJ (Richard - Communiteq)]

@ego-lay_atman-bay

I also mainly do not want the forum admins to have to enable it for every theme,

Installing a plugin is much more cumbersome than this and won’t work on Discourse.org hosted plans.

Besides, I think most forums only have one active theme.

Theme components can have settings and they can do everything that the Javascript side of a plugin can do. With the current state of the plugin you would not lose any functionality.

[ego-lay_atman-bay]

@RGJ

Installing a plugin is much more cumbersome than this and won’t work on Discourse.org hosted plans.

Don’t you just clone the repo into the plugins directory? I feel like that’s not very cumbersome. However, not working for the discourse hosted plans is valid.

@RGJ

I think most forums only have one active theme.

Not the forum that this plugin was made for. But I did just check, and it seems the theme component settings ui has had a massive overhaul since the last time I had to deal with them, so it looks easier to manage than I remember.

@RGJ

Theme components can have settings and they can do everything that the Javascript side of a plugin can do. With the current state of the plugin you would not lose any functionality.

I see, then I’ll try out rewriting it as a theme component, but I don’t think I’ll be able to get to it for a while due to other obligations.

[RGJ (Richard - Communiteq)]

@ego-lay_atman-bay

Don’t you just clone the repo into the plugins directory? I feel like that’s not very cumbersome.

Not all admins have command line access and not all admins who do, are very familiar with it.

And it requires a rebuild, which is not instant, can have side effects and can potentially lead to issues.

Updating a plugin requires a rebuild as well, while updating a theme component is the click of a button.

[NateDhaliwal]

@ego-lay_atman-bay

I see, then I’ll try out rewriting it as a theme component, but I don’t think I’ll be able to get to it for a while due to other obligations.

I might have a go at this later, since there really is no backend logic.

[ego-lay_atman-bay]

That would be helpful, since I assume you might know more about discourse than I do (this plugin was mostly hacked together from reading other plugins).