A Snap! Mod Idea (Part 3)

Continuing the discussion from A Snap! Mod Idea (Part 2) - #108 by warped_wart_wars.

Previous discussions:

Oh... Having grey blocks in non-Other categories is a kludge. Arguably even gray rings should be green rings, because they're reporters, like the other Operators blocks, or maybe some 11th color -- white rings or black rings or multicolor rings. (I wanted them to look like opals but couldn't talk Jens into it.) But I think I'd be happier if WARP were Control color and SCRIPT VARIABLES were Variables color, because beginners always get confused about where to look for them. Too late, I guess...

So if the code calls them Other in order to have them colored gray, I consider that an implementation kludge rather than a statement of principle.

When I try to press the Grey blocks category (The "Other" category), it does nothing. Is this category left blank for future updates?

And also, this is NOT a Snap! mod. All you did was change the names of the categories and that's it. Why is it a mod then?

Um, no. We are in early development. And we have changed many blocks. Please check your facts before posting.

There is no blocks in the other category by default. (There are, however hidden blocks in the "Other" category, but they aren't displayed, because, well... There hidden. :slight_smile:)

I was actually going to do that eventually.

I might replace them with BYOB 3 THE SCRIPT and THE BLOCK, but slightly better.

Yes. I want it to go to the Lists category when there are no blocks in the Other category. So the "it does nothing" you said is a bug.

Also I've changed the settings menu a bit.

Oh no no no no! Those were a huge mistake, not intellectually but pedagogically, and they were my mistake, so this isn't a story about how brilliant Brian came along to fix someone else's stupid design. All three iterations (the intermediate one was the one in which the white halo around an expression turned into a gray halo when you got close enough to an input slot) were my design. I'm really proud of the final one, because it reflects this pedagogic understanding: The difficulty many (most) people have with the abstract idea of procedure as data doesn't have to get in the way of them being able to use higher order functions, if the visual presentation deemphasizes the "lambdaness."

So, the key point in the final design is that the gray ring is part of the block (the HOF block I mean), rather than part of the expression you're going to put into it. You drag an expression into the gray ring, and you can semi-understand that the ring means to delay evaluation of the expression, and that's good enough for you to be able to use HOFs fluently.

We still have those unattached rings at the top of Operators, carrying the flag for the idea of lambda as a thing in itself, but nobody uses them in practice because we have the Ringify option in the context menu to get the same effect. And even that is needed only in unusual situations, such as wanting to make a list of procedures, as in the Vee example project.

When you want to write your own higher order procedure in Snap!, that's when you really have to understand lambda.

Oh. Maybe just change the color to green to match up with the rest of the category?

Edit: I'm actually doing that, and this:

IDE_Morph.prototype.topVisibleCategoryInPalette = function () {
    // private - answer the topmost (partially) visible
    // block category in the palette, so it can be indicated
    // as "current category" in the category selection buttons
    var top;
    if (!this.palette) {return; };
    top = this.palette.contents.children.find(morph =>
        morph.category && morph.bounds.intersects(this.palette.bounds)
    );
    return top ? top.category : null;
};

has been shortened as a result. (that's the shortened version)

Apparently, blocks' labels are in the Verdana font:

SyntaxElementMorph.prototype.setScale = function (num) {
    ...
    this.labelFontName = 'Verdana';
    this.labelFontStyle = 'sans-serif';
    this.fontSize = 10 * scale;
    ...

I really don't understand why you guys want "Single pallete" mode? In Scratch custom blocks have a separate category.
In Snap! "single pallete" mode, creating and looking for custom blocks become extremely counterintuitive.

palette

It's disableable, and I was working on saving it for the user, but when I do it, it errors.

Look at this:
untitled script pic (92)

I downloaded the source code. I can't change into any category other than control.

Yeah, I always have that problem when I change the code for switching to categories. I'm currently in the middle of debugging it. I'll tell you when I'm done.

You don't have to download the source code, you can just go here: Text-Based Snap!

Did you know you can put formatting in links? I.e., [*example*](https://example.com) example.

Edit: I didn't know that was an actual website!

Only "Other" works now.

Yes, I think I may have fixed it, just wait a minute.

Edit: Working now! Issue closed.