Please fill out these questions for all feature requests and bug reports. If you're requesting a feature, please let us know why this feature is important or useful, not just what it should do.
Thanks!
What browsers show this problem? Firefox and Chromium
Please share an example project (if possible).
Describes the steps to reproduce this issue. Open Snap!, drag set pen colour into script, put a reporter in set pen colour block, create custom block, add colour input to custom block.
What does Snap! currently do? Not allow reporters in %clr and not allow %clr in custom blocks
What should Snap! do instead? Allow reporters in %clr and have a button to switch input type to %clr
Is this bug a security concern? no
If so, please do not post security concerns directly to the forum. Please email us at contact@snap.berkeley.edu. Thank you!
I have taken the liberty of moving this from bug reports to feature requests. Colors aren't first class in Snap!, so you shouldn't expect the behavior you're expecting -- but it's a perfectly reasonable thing to want, in the spirit of "everything first class," and maybe someday you'll get it, although it's very low on the list.
Partly, I think you may not realize how much you're asking for. In order to make first class colors really useful, we'd want a whole algebra of colors, so you could say things like
What we have instead is first class lists, which can be used to make RGB or RGBA or HSV or HSVA or HSL or HSLA color representations. Then you can do plain old arithmetic on the numbers to combine colors as you like. So, for example, although the
block doesn't let you drag a reporter over the color input, the
block does, and so does the
block in my improved color system; it takes a list of three or four numbers as input.
What does a colour input return then? Just because it is missing from the custom block input selector doesn't mean it doesn't work. And what does new Colour() return?
It doesn't have that block, but blue (a scratch 2.0 mod) has colours, and that worked well enough (before flash went) All I did was make those blocks. But there was a problem that I couldn't use the colour input, so I made a bugfix and put it in my project. I am asking for that to be implemented into Snap! (it is robust enough to be used directly in block.js and byob.js) I could submit a pull request, but the custom block fix was badly implemented enough to request someone else to make a better one. I should probably replace it with a firefox extension like I used to do with scratch.
I dunno, some data structure, probably there's one native to JS. Yes, we could expose that to users, and have first class colors, and yes, it'd be cool for users to be able to use it in custom blocks. I'm not saying it's a terrible idea, just that there's a workaround and so we're unlikely to think about it in the near future.
At some time we're going to rethink how types are handled; some teachers are bugging us to let users optionally declare the return type of a reporter, and then if we have that information, use it to prevent dropping the wrong type into a typed slot. But this is not imminent.
Colors are, of course, first-class in the underlying Morphic code, but, as Brian correctly points out, not exposed to the Snap!-level.
Hach, these discussions are making me uneasy. Can we make a clearer distinction about people that are interested in the implementation of Snap and those wanting to do cool projects with Snap! I'm way more interested in the latter...
In the meantime, you can make a block that takes colors as inputs using my tool
Afaik it returns some sort of 'rgba' vector which you can strip r, g, b, and a components using JavaScript but I don't know how you would make new colors.
Jens, we could try reorganizing the forum so that there would be, as in Scratch, a toplevel Advanced Topics category and rearrange the other things so some topics would go under AT. Wanna do that?
that's a great idea, Brian! My concern is that I'm seeing a bit too many inquiries about subjects that might scare off our real target audience, because they might get the impression, that this forum is for ... only.
Oh wait actually, it is an object of type Color!
In JavaScript, you can use
return new Color(R, G, B, A);
R, G, and B are 0 - 255 but alpha appears to be 0 - 1.
If you want a good example of how to use this, here are some custom blocks: Color Blocks Library
Have fun toying around with it in the meantime unless they do plan to open up more of their API and enable flags for most of their features so stuff like this doesn't have to be done the hard way.
The nitty gritty
This is one of the main things that can be annoying in Snap!, since even in Developer Mode a lot of things are hidden to you when you can so easily edit them in XML or JavaScript... (But to do so, you would need to heavily study the source code and properties!!!)
Thus, this feature request sort of coincides with my concept of enabling more things to the user (at least in developer mode) so I don't have to be so hacky. (If developers want a reference, just check out how I do my type [ ] reporter in my XML generator)
The color reporter was made using the generator. To do it manually, %clr is the type you're looking for, and it can also be in multiples with %mult%clr.
If you want to use color as an input, just set it to number and use my color block. I know it isn't a number but it's round and doesn't automatically ringify almost all reporters.
Do note that unfortunately, the pen color cannot be assigned to by the color block unless also doing that by JavaScript. Added this myself. Seems that this is how it's done in the core scripts / source code too.
Moderators could move any "advanced topic" to this "AT" category. Maybe a topic are not "advanced" at the beginning... but long discussions turn topics to this way. So, we can dynamically move them.
And we have a Development category. Development discussions could be moved there... but also, I suggest to make these discussions to our github space.
And about the new categorization, I suggest to put "Advanced Topics" alone and keep having the other categories: Mod and Extensions (now with Snap4Arduino and others will arrive) and Feature Request (with the sub-cat Forum, Website and Snap! inside). Why? Because the "problem" of these AT is not the really their subjects, it is more about the "hacky" content or the "ultra-level discussions" which can scare our users.
Then, topics inside these categories (extension questions or feature requests) will also be moved to AT if they turn into this way.
