Hello! I was wondering if I could have blocks with multiple colors in the same custom category. I'm looking for something similar to script variables ((a)) @addInput being gray within the orange Variables category.
Thank you!
short answer: no :(
but bh (if not jens) wants collapsible sub-categories, and it would result in really good organization, even better than the space above checkbox.
I'd rather have sub-category headers instead of full sub-categories. I just want a way to mark sections and have multiple colors (or at least gray).
why? you could just decide to not close the subcategories, right?
Unfortunately, no, you can't. The primitive blocks are the exception. You can however turn on the single palette to simulate it. Combined with hide blocks, you can only show just the blocks you want.
When everything is nested, things get messy.
oh, it doesn't need to be nested from what I understand.
Could you explain this some more? I don't think anyone is suggesting sub-sub-subcategories, just one level below the palette category. If you look at the Control category, the worst offender, it's enormous, and you can't find things, but if you look more carefully you find that there are the things everyone needs all the time, like loops and IFs, and then there are the groups of advanced features that most users don't need at all, and even the hackers don't use in every project, certainly not all at once: clones, scenes, metaprogramming, internal definitions. If those were buried under subsection headers, the whole palette would be easier to swallow. If you twist my arm I might even allow as how the function-as-data ones (run, call, launch, pipe, tell, ask) could be buried under a section header.
Burying some primitives could also arguably be used pedagogically, e.g., make a subcategory of the four imperative-style List commands so you have to ask to see them. :~) I know, everyone would hate that. But just consider it as a gedankenexperiment.
As for the initial request in this thread, if anything I want to do the opposite, breaking up Variables into three categories (one of which would initially be empty). (And, don't tell Jens, but I would have made SCRIPT VARIABLES and WARP use the colors of the categories they're in.) I've been proposing to split Variables for a long time, but in the past Jens has opposed it because adding a fifth row of category buttons would have taken precious space away from the palette itself. But now that we have custom categories (with double-width buttons!), I think that ship has sailed and it's time to revive this idea. As it is, a new user who sees List blocks in a project has no idea where to find them in the palette.
Oh, I don't oppose the idea of subcategories, but I think that they should be represented as collapsable sections with headers rather than reusing the category GUI with indentation. (I should've explained this better.)
I might like this. I really want functional-style List reporters to replace the imperative ones so that temporary variables don't have to be used. (I know I can make my own.....but I just get excited about list manipulation that isn't tied to the lists' sources.)
DO IT. WE NEED THIS.
What about color contrast...?
Oh, right. I think that's the plan, to the extent that there's a plan at all... :~)
Not sure I understand what you're asking. I think I'm remembering correctly that Jens's idea for making SCRIPT VARIABLES grey was that you should think of it as a declaration rather than an executable command (although it actually is executable; it means something to put it in the middle of a script), rather than to make it stand out in the palette. I don't remember what his idea was about WARP, but it was a specific idea, not just wanting WARP to stand out. (If I were going to pick a block in the Control category to stand out, it'd be CALL! :~) )
In my opinion, the gray background lets the orange upvars to stand out, improving the legibility of the script.
Why are the "regular" variables declared through a dialog and not a block in the first place?
because they're accessible by the entire project/sprite rather than a single script.
you can always use create vars library.
why make these harder to find? I always have uses for these. but really this could all be fixed if the subcategories we decide to open are persistent between projects.
if I was making snap, I would have actually done this, but now I would say the upvar on a variables category block doesn't look that good, while the warp block makes sense how it is because it groups code together better, since you are usually surrounding control-colored loops with the warp block (there's for each item, but still).
definitely. I always just end up using the search bar. but to fix this, really, metaprogramming should just be moved to operators! I mean, I know a non-control hat is weird, but considering join and split is already in operators, this isn't too much of a stretch.
literally why
I mean, there are barely any variable blocks, and imho inherit makes more sense in control, because it exclusively deals with clones, so I think renaming the category to data and recoloring everything to the current lists color makes more sense.
I surprisingly 100% agree, I wish we could just move the category selector to the left or right of the palette with it being scrollable to support custom categories, which would make it really easy to justify splitting vars, lists, and other, and give us lots of much-needed extra space in categories.
And they let you choose between global and sprite only.
i know, that's why i said
Well, you didn't specifically say that you had to be able to select either of them.
Oh, you know, to not limit the length of a user-defined category name. I think some of the SciSnap! categories are too long to fit in the small buttons used for built-in categories.
yeah, that makes sense. but I would much prefer an option to make them smaller to keep precious palette space.
This would make sense, but I'm too used to it lol.
I think warp {
} should definitely be it's control color, but for script variables ((a)) @delInput@addInput I think "other" fits it. My reasoning for this is that, it's a block, yes, but it's not something that really functions.
For example, you can just make it yourself by making a multi-input with group 12, no code even necessary in the block.
I don't really see what those things have to do with each other. You seem to be saying that anything you could make as a custom block isn't "real." :~)