New Snap! Extensions Framework?

Advanced Topics Mods & Extensions
1

@Technoboy10 has one here: https://github.com/Technoboy10/snapext but in the repo description it says that it's depreciated. However, I can't seem to find a newer alternative. Is one available?

2

It's not maintained currently (native JS in Snap! + the arrival of ScratchX made it kinda irrelevant).

3

Connor's right. We were working on a Grand Unified extension framework for writing one extension in Python, that seamlessly worked with both Scratch and Snap!, patched over all the bugs in Scratch's HTTP, handled Unicode correctly, and even generated .xml/.sbe files for you.

Sadly, the ST killed off HTTP extensions, and so blockext was never finished. Sadness.

EDIT: since the grand plan is to support ScratchX (.sbx?) in Snap!, ideally new extensions should be written as ScratchX extensions. I guess it's plausible that there'll be extensions which still require a Python component (although AJAX and the Scratch Device Plugin helper for USB devices should cover most use cases); maybe someone should write a convenient compatibility layer for this? (Or just use something like snapext, but from JS?)

4

I know, Bernat (who does BeetleBlocks, among other things) was thinking of having some JS mapping from Scratch → Snap!, but I don't know what happened with his work.

Personally, I think there are two things:

  • scratch compatibility
  • snap-only extensions

The goal of Scratch compatibility could either be a "live" tool that at runtime converts a ScratchX plugin, or a stand-alone converter.

The Snap!-only part would focus on what you can't do with the current JSFunction block, and capabilities beyond the current Scratch Device Plugin, or maybe some bridge for that??

That's super-duper high level, and I'm not sure it says anything that's non-obvious, but those would be my two basic goals.

As far as implementation:
Most of these hardware plugins require something to be installed -- that severely limits options to something that is cross platform, or browser plugins. What I would love to see is a plugin architecture based on Github's Electron API (https://electron.io) and standard NPM packages.

Electron itself would give us an easy container to serve Snap! on the desktop. From there an API / framework should make it easy for extension authors to define a list of requirements to be installed, and then give some set of blocks which would be automatically loaded, like a library is.

Blockext tried to make it really easy to for authors to write blocks in python -- I don't think we need to do that for a while. I think if we provided a "native" API, then extension makers could just write blocks using Snap!'s JSFunction. They could also use HTTP if they wanted to, but wouldn't be limited to it.

There are two future things I'd like to two for an extensions interface:

  • support easily defining blocks in code. Maybe this could just be a stupidly simple JSON file:

{
spec: "my %inp clever %dates function %clr",
function: "myAPI.myFuncation(paramters)",
helpText: "This does something cool",
helpImage: "path-to-my.png",
type: "command",
category: "control"
}
```
These blocks would get automatically loaded into Snap! and would look like primitives. (Which might be an improvement from just custom JS blocks in some cases.)

  • Support dealing with multiple HTTP extensions automatically.
    One big problem with HTTP extensions is that they are tied to a set URL and port. If this changed from the provided library, then things get dicey very quickly and users need to figure out which blocks to edit. I'd like there to be a way for local APIs to not need to worry about port numbers or localhost URLs or whatnot.

As far as other things we could do:

  • all plugins can easily be hosted on npm
  • dependencies can be handled via npm install or some other method to resolve package.json
  • The directory of plugins could be maintained in any number of ways, such as a manual list, or via package naming conventions or keywords.
  • Snap! XML files would maintain a list of plugins and when loaded in places that plugins aren't supported users would be notified.

While hardware is a focus, I don't want to specifically think of these as hardware focused. It would be cool to have extensions which add native file system access or ship off data processing to lower level APIs, or that add functionality to the Snap! UI.

1 Like
5

Hi there!

Indeed, I started working on an extension mechanism a while ago, but I actually only got started...

In fact, it was just a Scratch extension loader for Snap!. It's just a few lines of code, but it was able to load simple extensions like the Sound Synth one or even the Scratch3D one. If you want to take a look, the code is really short.

https://github.com/bromagosa/Snapi/tree/extensions

Relevant file is extensions.js.

Also relevant are the menu entry for loading an extension via URL and the new labelPart for extension-loaded dropdown inputs.

6

Ooh, I like this! Do you have any idea whether it's possible to extend this to work with the Scratch Device Plugin as well?

7

Should be totally feasible, yep!

8

I guess specifically I wondered whether their plugin has any form of URL whitelisting. I've never gotten around to doing a proof-of-concept to check...

9

Oh, you're right... they may be doing that indeed.

Actually, someone tried to use my extension loader with the Device Plugin and it didn't work, maybe you can give it a shot (I don't own any EV3) and see if you can debug it.

10

I've just remembered that the Scratch Device Plugin doesn't work on free operating systems, so even if I owned an EV3 I'm afraid I wouldn't be of much help here... :pensive:

11

what’s that?

12