Discuss Scratch
- Discussion Forums
- » Advanced Topics
- » Snap! Team development discussion, vol. 2
- blob8108
- Scratcher
1000+ posts
Snap! Team development discussion, vol. 2
(continuing from the user thread) Is Snap's approach of editing blocks in a separate dialog significantly better than Scratch's model, where the block gets its own hat block/script in the same pane as the rest of the scripts? If so, why?
- cycomachead
- Scratcher
100+ posts
Snap! Team development discussion, vol. 2
(continuing from the user thread) Is Snap's approach of editing blocks in a separate dialog significantly better than Scratch's model, where the block gets its own hat block/script in the same pane as the rest of the scripts? If so, why?
Empirically or design-wise or what? From my perspective, I like blocks in a window better because it helps me focus on a particular script, sorta like importing a library in another environment. You don't need to see all that code. Scratch's model is definitely simpler. There's less moving parts and it's easy to find a block definition, but I don't know that it'd scale well to the number of blocks many Snap! projects have.
Also, I don't like the idea of defining a global block in the scripts pane of a particular sprite. It just feels like the wrong place of that code.
- djdolphin
- Scratcher
1000+ posts
Snap! Team development discussion, vol. 2
Scratch works around that by not having global blocks. Also, I don't like the idea of defining a global block in the scripts pane of a particular sprite. It just feels like the wrong place of that code.
It's kinda stupid…
!
- bharvey
- Scratcher
1000+ posts
Snap! Team development discussion, vol. 2
Yes, exactly – it's not an option for us to do it their way. Scratch works around that by not having global blocks.
But also, Scratch kind of assumes you're not going to have very many custom blocks. If you're doing a serious Snap! project, you really don't want 50 blocks cluttering up your scripting area.
@-io-: I tried installing Violentmonkey (what a name!) but can't get it to do anything. When I click on its icon, I see an empty one-line text window, and clicking on it does nothing. I hypothesize that it's empty because it assumes that everyone has their browser set to black on white. Anyway, I clearly can't ever run 55 because it doesn't let you run non-Mozilla-approved extensions. (Was Mozilla bought by Apple or something?) So when I get a chance I'll see if I can figure out which script is messing up.
- comp09
- Scratcher
1000+ posts
Snap! Team development discussion, vol. 2
Tampermonkey has worked well for me. It's a pure WebExtension.Yes, exactly – it's not an option for us to do it their way. Scratch works around that by not having global blocks.
But also, Scratch kind of assumes you're not going to have very many custom blocks. If you're doing a serious Snap! project, you really don't want 50 blocks cluttering up your scripting area.
@-io-: I tried installing Violentmonkey (what a name!) but can't get it to do anything. When I click on its icon, I see an empty one-line text window, and clicking on it does nothing. I hypothesize that it's empty because it assumes that everyone has their browser set to black on white. Anyway, I clearly can't ever run 55 because it doesn't let you run non-Mozilla-approved extensions. (Was Mozilla bought by Apple or something?) So when I get a chance I'll see if I can figure out which script is messing up.
- bharvey
- Scratcher
1000+ posts
Snap! Team development discussion, vol. 2
The color picker in that Scratch Blocks preview is prejudiced against orange. If you choose orange in the hue slider, then move either of the others leftward, the hue one moves left also, from orange to red. So it's really hard to get a true brown.
- _nix
- Scratcher
1000+ posts
Snap! Team development discussion, vol. 2
It's changing the other sliders when you move one.. that almost definitely seems like a misfeature. I guess they're picking the closest RGB value for a given HSB? (Do all HSB values have an exactly-equivalent RGB, given 255-red/green/blue format?) The color picker in that Scratch Blocks preview is prejudiced against orange. If you choose orange in the hue slider, then move either of the others leftward, the hue one moves left also, from orange to red. So it's really hard to get a true brown.
══ trans autistic lesbian enbydoggirls // 16 17 18 19 20 21, she/they ════
sparrows one word to the paragraph // <3 // ~(quasar) nebula
- bobbybee
- Scratcher
1000+ posts
Snap! Team development discussion, vol. 2
Do all HSB values have an exactly-equivalent RGB, given 255-red/green/blue format?
Assuming I understand the question correctly, no, they do not (err… I think? I'm maybe too tired to be making statements like that :S).
Last edited by bobbybee (Oct. 2, 2017 00:37:56)
“Ooo, can I call you Señorita Bee?” ~Chibi-Matoran
- bharvey
- Scratcher
1000+ posts
Snap! Team development discussion, vol. 2
I don't think the finite resolution of RGB and of HSV are enough of a problem to make a visible difference in the position of those fairly short sliders. Certainly you can make both orange and brown in RGB!
- _nix
- Scratcher
1000+ posts
Snap! Team development discussion, vol. 2
visible difference in the position of those fairly short sliders. Certainly you can make both orange and brown in RGB!Yeah, but if it's doing RGB approximations of HSV I don't think the finite resolution of RGB and of HSV are enough of a problem to make a as you drag and then updating the sliders to the HSV approximated RGB, you end up doing a whole lot of rounding, which I imagine is what's causing the sliders to move around while we drag.
(Edit: I think the simple solution would just be to not do any approximation until the value is selected? Or (since live-ly “RGB-ifying” the color is necessary so that the Scratch interpreter sees the color as you're change it), to not update the slider values while the user is in the dialog?)
I noticed that thisandagain, one of the developers of Scratch 3.0, just loved a project called “Stop Prejudice” …is prejudiced against orange.
Last edited by _nix (Oct. 2, 2017 16:28:24)
══ trans autistic lesbian enbydoggirls // 16 17 18 19 20 21, she/they ════
sparrows one word to the paragraph // <3 // ~(quasar) nebula
- bharvey
- Scratcher
1000+ posts
Snap! Team development discussion, vol. 2
as you drag and then updating the sliders to the HSV approximated RGB, you end up doing a whole lot of rounding, which I imagine is what's causing the sliders to move around while we drag.If I'm understanding you correctly (I'm really not sure), you seem to be suggesting that after each teeny move of a slider, the UI has to convert to RGB in order to display the colors on the sliders, Yeah, but if it's doing RGB approximations of HSV and then use that converted value as the starting point for the next teeny move. But there's no reason they'd have to do that; each move would be based on the previous HSV values. So the roundoff errors wouldn't have to accumulate.
(As proof of this, fire up Photoshop or something and slide around its HSV sliders!)
- _nix
- Scratcher
1000+ posts
Snap! Team development discussion, vol. 2
Yeah, I wasn't being very clear; sorry. I expect something like this is happening..
I think getting rid of step 5 here would fix the problem, since then the sliders would just stay as whatever color you've entered. (Step 4 is important so that Scratch updates the block while you're changing the color value, which makes it easier to play with; e.g. if you have a “forever, set pen color, draw square” script, then the drawn square's color will update while you have the color dialog open.)
Yeah, that's what I was thinking, actually. And you're right; there's no reason. I just think this is a bug!
Then again, I haven't been looking at any of Scratch's code while debating all this, which makes it fairly silly of me to make conjectures about the problem like this
- The user drags out a “set pen color” block.
- The user clicks on the color dropdown.
- The user changes the value of one of the sliders.
- Scratch converts the HSV value, from the sliders, into an approximate RGB value, which it inserts into the “set pen color” block.
- Scratch detects that the color in the “set pen color” block has been updated, so it converts the block's RGB value into an approximate HSV value, and updates the sliders to reflect this.
I think getting rid of step 5 here would fix the problem, since then the sliders would just stay as whatever color you've entered. (Step 4 is important so that Scratch updates the block while you're changing the color value, which makes it easier to play with; e.g. if you have a “forever, set pen color, draw square” script, then the drawn square's color will update while you have the color dialog open.)
you seem to be suggesting that after each teeny move of a slider, the UI has to convert to RGB in order to display the colors on the sliders, and then use that converted value as the starting point for the next teeny move. But there's no reason they'd have to do that; each move would be based on the previous HSV values. So the roundoff errors wouldn't have to accumulate.
Yeah, that's what I was thinking, actually. And you're right; there's no reason. I just think this is a bug!
Then again, I haven't been looking at any of Scratch's code while debating all this, which makes it fairly silly of me to make conjectures about the problem like this
══ trans autistic lesbian enbydoggirls // 16 17 18 19 20 21, she/they ════
sparrows one word to the paragraph // <3 // ~(quasar) nebula
- bharvey
- Scratcher
1000+ posts
Snap! Team development discussion, vol. 2
Oh. I don't think a single round trip would cause that much inaccuracy. It doesn't happen anywhere but orange. And RGB is capable of expressing a wide range of oranges!
- Scratch converts the HSV value, from the sliders, into an approximate RGB value, which it inserts into the “set pen color” block.
- Scratch detects that the color in the “set pen color” block has been updated, so it converts the block's RGB value into an approximate HSV value, and updates the sliders to reflect this.
Last edited by bharvey (Oct. 3, 2017 15:11:43)
- bharvey
- Scratcher
1000+ posts
Snap! Team development discussion, vol. 2
@birdoftheday: Can you read this one?
- birdoftheday
- Scratcher
500+ posts
Snap! Team development discussion, vol. 2
Your new icon? Yes. What's it from?
Am I the only person who likes 3.0 better than 2.0, or do the people who do just not talk about it?
- bharvey
- Scratcher
1000+ posts
Snap! Team development discussion, vol. 2
It's from Girl Genius, a webcomic that probably doesn't meet Scratch standards of G-rating, but it's, I don't know, PG-13 or so. And really funny and interesting. Your new icon? Yes. What's it from?
P.S. I don't really hate my entire life, it's just that for the next few weeks I have an impossible amount of work to do (including updating the manual for 4.1 and some changes to libraries).
Last edited by bharvey (Oct. 14, 2017 21:36:54)
- bharvey
- Scratcher
1000+ posts
Snap! Team development discussion, vol. 2
We just got some statistics from MioSoft, our back end provider. As of Aug 12 there were 26,000 Snap! users worldwide, and since then there are 20,000 new ones.
Some of those are going to be people who forgot their password or wanted a second account for some other reason, but even if that were half of the new accounts, that would be 10,000 new actual people!
Edit: Jens thinks this is a typo and it was actually 126K in August, based on earlier reports.
Some of those are going to be people who forgot their password or wanted a second account for some other reason, but even if that were half of the new accounts, that would be 10,000 new actual people!
Edit: Jens thinks this is a typo and it was actually 126K in August, based on earlier reports.
Last edited by bharvey (Oct. 15, 2017 00:24:48)
- _nix
- Scratcher
1000+ posts
Snap! Team development discussion, vol. 2
Still, that's a pretty big bunch of new people! Edit: Jens thinks this is a typo and it was actually 126K in August, based on earlier reports.
Edit: unless it went from 126K to 46K, in which case, oh no
Last edited by _nix (Oct. 15, 2017 12:15:12)
══ trans autistic lesbian enbydoggirls // 16 17 18 19 20 21, she/they ════
sparrows one word to the paragraph // <3 // ~(quasar) nebula