Feature request: Favorites palette

It would be super awesome if there could be a palette called 'Favorites'. Any block (built-in or custom) in any other palette could be dragged onto the tile for the Favorites palette, and a copy/link would be in there. The Favorites palette would only contain copies/links of blocks that 'really' exist in actual palettes.

This would make Snap! a lot quicker/easier to use, much less switching between palettes (mentally context-switching) and hunting for specific blocks in long lists (that sometimes scroll off the screen).

To remove a block from Favorites, right-click 'Remove from Favorites' (or drag from the palette to the palette-tile area?), confirm 'Remove block from Favorites palette? (the block will still exist in its normal palette)'. Right-click menu could still have 'delete block definition...', 'duplicated block definition...' and 'edit...'

Probably need to add File/Export Favorites along with Export Project and Export Blocks. If any custom blocks are in the Favorites, include their definitions in the exported xml. When importing a Favorites.xml, it might be tricky to deconflict if a custom block has already been imported from a Blocks.xml (how is that handled currently if a Blocks.xml is imported which contains a custom block already in the project?)

To keep things organized, it would be good if inside the Favorites palette (and why not also inside all palettes?) blocks can be dragged around to reorder, maybe leave in specific positions instead of an equally-spaced list, maybe can add/remove separators between desired blocks.

A new Snap! project could have Favorites populated with a default collection of standard blocks. A good start might be the relatively small number of blocks used by BJC units 1 and 2.

there's a whole category for feature requests. you should move it there

Thanks, I looked but didn't see that as a sub-topic under advanced! Hopefully it's not one that's already been requested a brazillion times

So close -- this is not a feature request for the forums.

whoopsies, found the wrong 'Feature Request' sub-topic! Hopefully it's in the right place now as a Feature Reqeust for Snap! itself!

Yes it's in the right place now.

Would the Favourites palette be like the Backpack in Scratch?

It's an interesting idea. To address @donotforgetmycode_sn's question: The name "favorites" suggests a per-user property, but some of the details in the proposal make it sound to me more like a per-project property. If the list includes custom blocks, at least some of the ones in the list may be project-specific, especially since we've made most of the former Tools blocks primitive. Per-user would be interesting to me iff we also have per-user startup libraries that are automatically loaded into every new project. But per-project is good for teachers who want to give students "only use these five blocks" problems; they just put those blocks in Favorites (and we make Favorites the default initial category instead of Motion) and save the project.

I don't like the OP's final paragraph about a default Favorites selection. That's kind of Orwellian: "These will be your favorites." Better we have starter projects in BJC that load a project-specific Favorites list.

Yeah, you got the idea. It would definitely be useful (I think) to have a per-user memory between projects, rather than making users reimport the same Favorites.xml every time.

Why not generalise the suggestion? Why only one new palette? Why not let the user name (or rename) them? And hide some as well.

Regarding user-specific versus project-specific why not make everything project-specific but add the feature that a user can specify what project(s) should be loaded when Snap! is launched without a project name (and the project remains unnamed).

What should be loaded into a new project is a library, not a project. But, I see, you want the new project to start with a Favorites palette.

The usual answer to "why not generalize" is "If we make this too big of a thing, Jens won't implement it." But I dunno, we'll talk about it. He does want users to be able to make new palette categories.

I somewhat have that implemented in this project: https://snap.berkeley.edu/snap/snap.html#present:Username=snapenilk&ProjectName=Snap!%20Dev%20tools&editMode&noRun

You could probably patch the project save code (serialization) to know about your new categories, but I don't see how you can solve the load (deserialization) problem, because of its chicken and eggness.

Possible ghetto implementation with current release: create a custom block called 'Favorites'. Don't actually build a block in there, just drag your favorite blocks in, organize how you like. Keep the edit window open, maybe stretched tall & skinny next to the stage/corral. Instead of hunting/pecking for blocks in all the palettes on the left, just duplicate them out of the edit window full of Favorites on the right.

Also can export as a Block xml and reimport into other projects.

Slight limitation: You can't change to a different sprite with an edit window open.

Right, I want something that is a library (i.e. a bunch of blocks) PLUS selected global settings and things like which blocks are hidden, new palettes (when implemented), .... A project is too much and not enough.

And is there a form of the URL that starts Snap! with a list of libraries?

No, you're right, loading a project is the easiest way to do what you want. Your project can use the getters/setters library to set its name back to Untitled (or whatever the local translation is).