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
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!.
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.
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.
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.
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:
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
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)?