Discuss Scratch
- Laternenpfahl
- Scratcher
500+ posts
Pen, touching changes please!
Please finally add full RGB/HSL support for the pen and touching blocks, if possible also a
block, which has in the dropdown menu:
H (hue)
S (Saturation)
L (luminosity)
R (Red)
G (Green)
B (Blue)
The values returned for this block would be 0 to 100, to stay with the current specifications.
In conclusion, the blocks added would be:
EDIT:
Simplified by nxiii:
([H v] at x[10] y[10])
block, which has in the dropdown menu:
H (hue)
S (Saturation)
L (luminosity)
R (Red)
G (Green)
B (Blue)
The values returned for this block would be 0 to 100, to stay with the current specifications.
In conclusion, the blocks added would be:
[set pen color to H:[] S:[] L:[]]
[set pen color to R:[] G:[] B:[]]
(touching color H:[] S:[] L:[])
(touching color R:[] G:[] B:[])
([H v] at x[10] y[10]) (see above)
EDIT:
Simplified by nxiii:
(color hue: [0-200] saturation: [0-100]% lightness: [0-100]%)
(color at x: [0] y: [0])
([hue v] of [ ])
Last edited by Laternenpfahl (Dec. 10, 2012 23:49:26)
yeah, I'm still here
- Hardmath123
- Scratcher
1000+ posts
Pen, touching changes please!
I think we should retain the color/shade format, because it is easy for beginners to pick up. I would vote to replace shade with brightness. Also, I agree with (color at (x) (y)) and (brightness/shade at (x) (y)), which would be really useful.
- Laternenpfahl
- Scratcher
500+ posts
Pen, touching changes please!
okay! but then there is no good way for gray tones and such, thats why i proposed this
edit:
The old blocks would stay of course
edit:
The old blocks would stay of course
Last edited by Laternenpfahl (Dec. 8, 2012 10:30:28)
yeah, I'm still here
- Laternenpfahl
- Scratcher
500+ posts
Pen, touching changes please!
bump
Please add this!
Please add this!
yeah, I'm still here
- nXIII
- Scratcher
1000+ posts
Pen, touching changes please!
I would much prefer if they added these four blocks (first-class colors, the only good feature in Panther):
EDIT: To clarify, the top three blocks report colors; they can be used in any color slot but don't fit into other slots. The bottom one reports a number, and has six components (red, green, blue, hue, saturation, and lightness) in the pop up menu.
(color red: [] green: [] blue: [])
(color hue: [] saturation: [] lightness: [])
(color at x: [] y: [])
([red v] of [])
EDIT: To clarify, the top three blocks report colors; they can be used in any color slot but don't fit into other slots. The bottom one reports a number, and has six components (red, green, blue, hue, saturation, and lightness) in the pop up menu.
Last edited by nXIII (Dec. 9, 2012 20:31:43)
- Laternenpfahl
- Scratcher
500+ posts
Pen, touching changes please!
nXIIIOops, forgot to add that. Thanks
I would much prefer if they added these four blocks (first-class colors, the only good feature in Panther):
Actually, how about making colors strings in the RGB000,255,255 or HSL000,255,255 format?Or rather 0 to 100?
yeah, I'm still here
- Laternenpfahl
- Scratcher
500+ posts
Pen, touching changes please!
nXIIIOops, forgot to add that. Thanks
I would much prefer if they added these four blocks (first-class colors, the only good feature in Panther):
Actually, how about making colors strings in the RGB000,255,255 or HSL000,255,255 format?Or rather 0 to 100?
yeah, I'm still here
- nXIII
- Scratcher
1000+ posts
Pen, touching changes please!
LaternenpfahlI think it would be confusing if they displayed like that (a little square of the color is more intuitive), but I guess they could cast to rgb(100, 100, 100) or something instead of refusing drops into string slots.
Oops, forgot to add that. Thanks
Actually, how about making colors strings in the RGB000,255,255 or HSL000,255,255 format?Or rather 0 to 100?
I really like the idea that Scratch makes it hard to make errors like that, though; there are very few times (I can't think of any right now) when I would want to directly place a color where a string or number should go. As long as we have a (component of color) block, I would prefer if we didn't let users drop color blocks into string slots.
Last edited by nXIII (Dec. 9, 2012 21:20:34)
- Laternenpfahl
- Scratcher
500+ posts
Pen, touching changes please!
Great idea! so a
block
Color variables? Maybe a checkbox next in the new variable dialog? Edit: not needed with the above blocks tho
[rgb ()()()]
[hsl ()()()]
Color variables? Maybe a checkbox next in the new variable dialog? Edit: not needed with the above blocks tho
Last edited by Laternenpfahl (Dec. 9, 2012 21:33:37)
yeah, I'm still here
- nXIII
- Scratcher
1000+ posts
Pen, touching changes please!
LaternenpfahlYes, but I'd prefer if they were (red: _ green: _ blue: _) and (hue: _ saturation: _ lightness: _). Traditionally the scales are 0-255 or 0%-100% for all but hue, which is 0-359 degrees or 0%-100%. If we do use the scale 0-100, we should probably put percent signs in the above blocks so users familiar with RGB or HSL color spaces are not confused.
Great idea! so ablock[rgb ()()()]
[hsl ()()()]
Color variables? Maybe a checkbox next in the new variable dialog? Edit: not needed with the above blocks thoThat's a good point. I think color variables would be a bad idea, but if we let users assign colors to normal variables we do have to deal with the casting problem. I think colors should cast to the string rgb(red, green, blue) when they are used in blocks which take strings as arguments and should cast to 0 when they are used in blocks which take numbers as arguments.
Last edited by nXIII (Dec. 9, 2012 21:51:05)
- Laternenpfahl
- Scratcher
500+ posts
Pen, touching changes please!
nXIIIAlso cast to red if non color inside and try to be used as color
yeah, I'm still here
- Hardmath123
- Scratcher
1000+ posts
Pen, touching changes please!
New data type? Hmm.
First of all, I'd like to add some other blocks to nXIII's set,
where the * is a color input with a palette.
A couple of points:
1. Casting: This seems obvious enough, but I think it will be a bit confusing to new users. If you drop a color into a string input, do you get the rgb, or hsl? Or an error? What if you try to make it a number?
2. Storing: How will you store colors in variables? I don't see a point in allowing colors in variables but not lists. Even if we have color variables, it would make the palette cluttered. Can you store colors in the cloud?
3. Is it really such a good idea to make a whole new data type? How about keeping colors as a color/brightness stringed set separated with a comma?
First of all, I'd like to add some other blocks to nXIII's set,
(color [*])
(color of current costume at x:() y:())
A couple of points:
1. Casting: This seems obvious enough, but I think it will be a bit confusing to new users. If you drop a color into a string input, do you get the rgb, or hsl? Or an error? What if you try to make it a number?
2. Storing: How will you store colors in variables? I don't see a point in allowing colors in variables but not lists. Even if we have color variables, it would make the palette cluttered. Can you store colors in the cloud?
3. Is it really such a good idea to make a whole new data type? How about keeping colors as a color/brightness stringed set separated with a comma?
- Laternenpfahl
- Scratcher
500+ posts
Pen, touching changes please!
Hardmath123See the latest post. Colors would be stored as strings. Color of current costume at x y would be a bit specific and could be emulated easily.
New data type? Hmm.
First of all, I'd like to add some other blocks to nXIII's set,A couple of points:(color [*])
(color of current costume at x:() y:())
where the * is a color input with a palette.
1. Casting: This seems obvious enough, but I think it will be a bit confusing to new users. If you drop a color into a string input, do you get the rgb, or hsl? Or an error? What if you try to make it a number?
2. Storing: How will you store colors in variables? I don't see a point in allowing colors in variables but not lists. Even if we have color variables, it would make the palette cluttered. Can you store colors in the cloud?
3. Is it really such a good idea to make a whole new data type? How about keeping colors as a color/brightness stringed set separated with a comma?
If there is a nonvalid color, it would become red (color 0, shade 0)
Also, the colors could be stored in lists, what was ever said against that?
Last edited by Laternenpfahl (Dec. 10, 2012 22:34:03)
yeah, I'm still here
- Laternenpfahl
- Scratcher
500+ posts
Pen, touching changes please!
Lightnin, are you listenin?
Recap:
Anything that doesn't work casts to red.
Colors are strings and can be stored more easily that way. Thus, pen color blocks now accept variables. Again, anything that does not work is cast to red.
Blocks added:
That is only four spaces of palette! We can afford that right?
Recap:
Anything that doesn't work casts to red.
Colors are strings and can be stored more easily that way. Thus, pen color blocks now accept variables. Again, anything that does not work is cast to red.
Blocks added:
[[H v] at x[10] y[10]] <--- dropdown contents: H S L R G B
[rgb v () () ()] <--- note: dropdown! rbg and hsl are same block
[hsl v () () ()] <--- the problem with writing out the words is the valuable space in the palette. ST's decision though
[color [palette]]
[color at x: () y: ()]
[hue: () shade: ()]
That is only four spaces of palette! We can afford that right?
Last edited by Laternenpfahl (Dec. 10, 2012 22:56:07)
yeah, I'm still here
- Lightnin
- Scratcher
1000+ posts
Pen, touching changes please!
Hiya guys!
A few things - our focus is now moving to fixing bugs, completing features, and getting 2.0 out the door. As you may have noticed, lots of people are clamoring for it! So it's likely that we'll be less and less interested in making changes to the editor as time goes on. Even little changes often have unintended effects, and we need to minimize surprises now.
The other thing about these suggestions is that they definitely seem on the complex side. What would someone who has barely ever used a computer before (and never programmed anything) think about a block that says HSL? Or even RGB? My suspicion would be that they'd likely get confused.
As mentioned here, we need to keep things simple, so features like this one are hard to justify when that's one of our primary design goals.
I'm not saying it won't happen, but the case you'll have to make should start with: “This will be simple for people who are totally new to programming because…”
…and only after that go on to…
“This is an awesome feature that will make it possible for us to do…”
A few things - our focus is now moving to fixing bugs, completing features, and getting 2.0 out the door. As you may have noticed, lots of people are clamoring for it! So it's likely that we'll be less and less interested in making changes to the editor as time goes on. Even little changes often have unintended effects, and we need to minimize surprises now.
The other thing about these suggestions is that they definitely seem on the complex side. What would someone who has barely ever used a computer before (and never programmed anything) think about a block that says HSL? Or even RGB? My suspicion would be that they'd likely get confused.
As mentioned here, we need to keep things simple, so features like this one are hard to justify when that's one of our primary design goals.
I'm not saying it won't happen, but the case you'll have to make should start with: “This will be simple for people who are totally new to programming because…”
…and only after that go on to…
“This is an awesome feature that will make it possible for us to do…”
- Laternenpfahl
- Scratcher
500+ posts
Pen, touching changes please!
Lightninpeople who want to make anything involving the pen and pretty much any colors, especially grey tones are inconvenienced by having to make a loop for such grey colors or “non-pure” colors as there is no way to easily implement these.
This will be simple for people who are totally new to programming because
The old blocks stay, so it doesn't make the pen harder, but not simpler either.
Lightninmake better platformers, pen projects, or other things involving pen.
This is an awesome feature that will make it possible for us to
Basically, this won't interfere with old projects, and wouldn't break anything. This would increase the usefulness of the pen by a lot.
Note that the old blocks would stay. Why wouldn't they?
How about a survey? I'm sure most Scratchers would approve.
Last edited by Laternenpfahl (Dec. 10, 2012 23:49:59)
yeah, I'm still here
- nXIII
- Scratcher
1000+ posts
Pen, touching changes please!
LightninI know; I'm just thinking about some that might be nice to have in the future.
A few things - our focus is now moving to fixing bugs, completing features, and getting 2.0 out the door. As you may have noticed, lots of people are clamoring for it! So it's likely that we'll be less and less interested in making changes to the editor as time goes on. Even little changes often have unintended effects, and we need to minimize surprises now.
Here is my proposal.
“This will be simple for people who are totally new to programming because…”
- it avoids the common-in-computing-but-rarely-seen-elsewhere RGB color space in favor of HSL, a concept which is much more intuitive and which is already somewhat present in Scratch;
- it adds only three new blocks which are simple enough to be easily understandable but powerful enough to allow many new kinds of projects; and
- it makes it difficult to make a semantic error by only allowing users to assemble blocks which make sense in the context of the data on which they operate
Three new blocks are available:
(color hue: [0-359] saturation: [0-100]% lightness: [0-100]%) — Pen
(color at x: [0] y: [0]) — Sensing
([hue v] of [ ]) — Pen
Colors would be able to be stored in variables, and would display as squares of their color in variable watchers and value bubbles. If they were used where strings or numbers are expected, they would always stop the script and highlight the block in red (like division by zero).
No blocks except COLOR and COLOR AT and variable reporters would be able to be dragged into color slots; COLOR and COLOR AT would only be able to be dragged into color slots. Variable reporters would also turn red and stop the script if they reported a non-color to a block expecting a color.
SET/CHANGE PEN COLOR (to a number) and SET/CHANGE PEN SHADE blocks would be renamed to SET/CHANGE PEN HUE/LIGHTNESS to match the COLOR block (doing the opposite leaves (color color: _ saturation: _ shade: _), which is very confusing); the SET/CHANGE PEN LIGHTNESS block ends with a percent sign.
The scale of PEN HUE (and COLOR's hue component) would be adjusted to degrees, which makes more sense as hue is a circular measurement.
Last edited by nXIII (Dec. 11, 2012 10:16:53)
- Laternenpfahl
- Scratcher
500+ posts
Pen, touching changes please!
nXIII
snip
Kinda want rgb, but i can live without it.
Other than that, I fully support that.
Also, make the hue be in %, it doesn't fit in.
The old blocks need to stay though…
Last edited by Laternenpfahl (Dec. 10, 2012 23:51:34)
yeah, I'm still here