Ability to rename user-created categories after creation

As of now, if you wish to change the name of a category you create, you have to create a new category and move all of your blocks from the category you wish to change to the new category. Then, you have to delete the old category. It is a long process and becomes very annoying in projects with lots of blocks and categories.

Edit: it is easy to change the color, sorry, but definitely not the name

I absolutely agree, since the best way to do it right now is to use a script like this

(I used index of, because the category of block block returns a number)

Unfortunately, you need to manually create a new category if you want to fully move all the blocks to a new category (or use these blocks I made to create and delete categories, requires js though).

And please add to the Feature Request: change the order of blocks within a category!

By the way, changing the color of an existing category is feasible: pretend the category doesn’t exist yet and create a “new” category bearing the exact same name, with a different color.
You may need to save the project and re-open it to experience the result.

Could you explain the use case? I mean, why don't you just get it right the first time?

Changing the order of blocks: Yes, I want that too; there are some complexities about how to store the information in your project in a way that's robust against the palette contents changing in a new version of Snap!.

It's very difficult to judge how a certain color is going to look on blocks without any kind of preview.

This is irony, isn’t it?

You can already change a category color, you just can't rename it.

What if they have a typo or later think of a better name?

No, the order of blocks is something provided by Snap!, and it makes sense for a user to want to change it, without either us or them having made mistakes. Custom categories, though, are entirely user-created.

I can't tell if your being serious here :slight_smile:

We can rename variables/costumes/sounds, change the labelling on custom blocks - swap them between different categories etc etc

And your saying we should choose cat name/colour once and just be expected to be happy and live with it? :slight_smile:

well, that's a loose end. Currently you can only delete a custom category, and all of its blocks will go to the gray "other" category. Then you can make a new one, with a new name and / color, and move your blocks from "other" to the new custom category one by one (or using a script).

In a category with a lot of blocks, though, especially in a project with a lot of Other blocks, that is a tedious task. Perhaps an alternative feature could be the ability to select multiple custom blocks at once and change their category.

  1. I tried @ego-lay_atman-bay 's category transfer script (post #2), and it performed flawlessly. :+1:
  2. For the color issue there is also a practical workaround (post #3).
  3. Reordering blocks within a category remains extremely time-consuming, almost unfeasible.

And the 90% (or so) of Snap! users who don't frequent the Forum are just in bad luck even when they are looking for (1) or (2). :smirk: (for lack of an :irony: emoji)

well yes, as I said, it's a loose end. BUT, as I also mentioned, you can write a script in Snap! that reassigns those blocks to another category all at once rather than going through them one at a time.

Sorry, yeah, I missed that.

My theory (after some experimentation) of block positions within a category is each block has a property representing the moment it was created or copied into the project. The “oldest” block within a category is at the top of the palette. So if a user would like to change block positions within a palette, they may either:

  1. export the block, then import it; hence it will be considered the “newest” block (as a downside, all underlying custom blocks will also be “renewed”, and consequentially be moved to the bottom of their palette - so there’s more to it if one doesn’t want to leave a mess) - OR
  2. make a copy of the block (which will automatically be called “~ (2)”); modify all scripts calling the old block to hence call the copy; delete the old block; rename the new block. Now this is a lot of work, too.

Can you confirm (or refute) this is how blocks are positioned within palettes?
Do you agree creating a more user-friendly mechanism ought to be on the development teams’ backlog? (or even confirm it already is)?

And also changing block order could just modify this value

in v9 dev you can already do this:

(you can also - in the current version - just arrange them differently, e.g. sorting the by their label or whichever other way you like)

V9 dev?

At the time of this post, we are at version 8.2.3.
V9 Dev is the work-in-progress 9.0.0.