don't normally allow you to input variable inputs into them, so something like this isn't possible:
set pen color to (var)
But, from screwing around with the block that sets attributes of other blocks, I found out that this is possible. So why isn't it already like that?
On top of that, some of the color-related library blocks do allow you to put variables and other things in those slots.
I think that the normal blocks that have color inputs should be like that to start with, and not require the user to go mess around with some attributes for it to happen.
Albeit, now that I look at it, it doesn't work. It seems to just default to black?
(The set pen color to block. The library blocks interact with each other just fine.)
But my point still stands.
History. That primitive block long predates first class colors. And, I guess, technically, colors still aren't primitively first class; as far as Snap! is concerned, what you think is a color value in that variable is actually a costume value, so not technically eligible to replace the built-in color selector.
I don't understand. Seems to work for me:
Am I misunderstanding what doesn't work for you?
Yes, well. Trying to SET PRIMITIVE OF... TO FALSE is clever, but should probably be disallowed, because changing that attribute doesn't change the fact that the block is implemented as JS code, not as Snap! code. :~) And, as I said, as far as Snap! knows, a one-pixel costume is a costume, not a color. (The c&c library does a lot of work to interpret costumes as colors.) By changing the primitive flag you overcame the syntax checking, but SET PEN COLOR TO still expects a JS Color object, not a Snap! costume, as input. I'm kinda surprised you didn't get an error message, but it's still an error even if uncaught.
If you use the
block from the library, it works fine with the output from COLOR FROM.
Use the extension [clr_setpen(clr) V] (extension [clr_rgba(r, g, b, a) V] input list: (list [R] [G] [B] [A (0-1)] @delInput@addInput)) block. (P.S. enable extension [ V] @verticalEllipsis@addInput blocks by going into $-1$gears$-1 :: reporter #292929 then clicking [ Extension blocks])
P.S. 2: Drag in (list [R] [G] [B] [A (0-1)] @delInput@addInput) onto the three dots between the arrows in (extension [clr_rgba(r, g, b, a) V] [] @delInput@verticalEllipsis@addInput)
Explanation: [clr_setpen(clr) V] :: other expects a JS Color class to set the color. I think you can replace that with your replaceable set pen color to [#911a44]. But as other people said, using the libraries to get the color from RGB(A) is not very recommended
Alternatively, you can do set pen [RGBA V] to (list [R] [G] [B] [A (0-1)] @delInput@addInput).
They existed in JS! But Snap! isn't an alternate syntax for JS; it's its own language. We believe in that principle attributed to Einstein: Make things as simple as possible, but no simpler. That's why we took on the task of expanding Scratch in the first place. So, is a color type something you need in order to learn computer science? No, especially since you can fake it with 1x1-pixel costumes.
I confess, maybe starting with hyperblocks, maybe even earlier, our "as simple as possible" isn't all that simple. There's a deep conversation to be had about whether we've experienced mission creep. We rarely have the leisure for deep conversations these days, which is why Robolot is so useful to us, imho.
definitely mission creep. in fact, quite a bit more than mission creep, i think old features just keep getting forgotten about and discarded. when 10.1.0 released i wanted to point out that it's now the fourth form of inheritance i know of, and i never finished posting it because just filling out a table trying to explain them took too long.
i think i'll just post it unfinished in a new thread now so people can actually look at it.
that makes it not error
is not compatible with the color input.
