I think that custom blocks should have an option called "colour input" which adds a colour input, like the one in the Pen blocks.
Yeah, we need to rationalize colors altogether. Pen color options and costume color options are different, and we have to talk Jens into HSL, and all that. Really there should just be a color type, and it should have a full set of constructors and selectors. It'll come.
Isn't is HSL now? It should be RGB anyway…
It's HSV. Look up "HSL and HSV" in Wikipedia (some year, as the Snap! manual says, when you don't have anything else to do).
Of course we also support RGB; that's what the display hardware uses, mostly, and it's what you get when you look at a costume's pixel array. But when you look at the color picker, you don't see three knobs for R, G, and B; you see Hue on the X axis and L (not V!) on the Y axis. That's because V (called "brightness" in Snap!, a terminology not used by anyone else, I think) doesn't correspond to anything intuitively meaningful. (Well, actually, it wouldn't be so terrible if we called V "shade" and S "tint." which is what they are if you speak artist-speak, more or less, except that the range is backward; 0 should mean no shade or tint, full color, whereas 100 should mean black or white respectively. Unless both of them have intermediate values, in which case I'm back to "not intuitively meaningful.")
Kind of like the Panther color type?
Yes, that's what I envision, although last time we talked about it Jens wasn't convinced. We'll see. On my list is to invent abstract data type support, so colors could be implemented entirely in Snap! code. That's if we ever get the AP Endorsement process finished for BJC.
I'd like to have HSL instead of HSV very much.
It'll definitely be an option in my color library. The annoying part is that we can't just add Lightness as an option in the PEN block; "Saturation" means something totally different in HSL from what it means in HSV. So there will be two menu items "HSV Saturation" and "HSL Saturation." :~(
Maybe you could add a project-wide setting, like flat line ends and block zoom. That way, users could use what is easiest to them.
For HSL/HSV? I doubt it. For one thing, Jens would never go for it. But the other thing is, if we keep accreting settings, it becomes very hard for us to respond to requests to debug a user's project, because some flag won't be set the way we expect, or because the user is confused about how the settings are set. Something like flat line ends is (1) unmistakeable, and (2) set because of an actual need of a project, not because of the user's taste.
My color proposal is now available. See this post: https://forum.snap.berkeley.edu/t/request-for-comments-proposed-new-color-management-model/1313.