Pen, touching changes please!

Laternenpfahl

Please finally add full RGB/HSL support for the pen and touching blocks, if possible also a

([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

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

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

Last edited by Laternenpfahl (Dec. 8, 2012 10:30:28)

yeah, I'm still here

Laternenpfahl

bump

Please add this!

yeah, I'm still here

jji7skyline

+100%

This feature is really needed.

Check out the NEW PROBEHEAD ALBUM!

nXIII

I would much prefer if they added these four blocks (first-class colors, the only good feature in Panther):

(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)

♡ nXIII · GitHub

Laternenpfahl

nXIII
I would much prefer if they added these four blocks (first-class colors, the only good feature in Panther):

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?

yeah, I'm still here

Laternenpfahl

nXIII
I would much prefer if they added these four blocks (first-class colors, the only good feature in Panther):

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?

yeah, I'm still here

nXIII

Laternenpfahl
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 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.

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)

♡ nXIII · GitHub

Laternenpfahl

Great idea! so a

[rgb ()()()]
[hsl ()()()]

block

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

Laternenpfahl
Great idea! so a
[rgb ()()()]
[hsl ()()()]
block

Yes, 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.

Color variables? Maybe a checkbox next in the new variable dialog? Edit: not needed with the above blocks tho

That'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)

♡ nXIII · GitHub

Laternenpfahl

nXIII

Also cast to red if non color inside and try to be used as color

yeah, I'm still here

nXIII

Laternenpfahl
Also cast to red if non color inside and try to be used as color

That might be the best path for going the other direction as well (color -> string).

♡ nXIII · GitHub

Hardmath123

New data type? Hmm.

First of all, I'd like to add some other blocks to nXIII's set,

(color [*])
(color of current costume at x:() y:())

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?

Laternenpfahl

Hardmath123
New data type? Hmm.

First of all, I'd like to add some other blocks to nXIII's set,
(color [*])
(color of current costume at x:() y:())
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?

See 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.

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

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:

[[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

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…”

Laternenpfahl

Lightnin
This will be simple for people who are totally new to programming because

people 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.

The old blocks stay, so it doesn't make the pen harder, but not simpler either.

Lightnin
This is an awesome feature that will make it possible for us to

make better platformers, pen projects, or other things involving pen.

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

Lightnin
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.

I know; I'm just thinking about some that might be nice to have in the future.

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

RGB colors could be done with the COLOR block and HSL is a lot more intuitive to non-programmers. The COLOR AT block is really useful for a number of things, including blending, scanning, sensing, and image effects. The component accessor block is useful for those kinds of things as well, and these blocks would work really well with the video sensing blocks.

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)

♡ nXIII · GitHub

Laternenpfahl

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

Discuss Scratch