Snap! Team development discussion, vol. 2

-Io-

I changed from Greasemonkey to Violentmonkey when Firefox 57 stopped supporting legacy extensions, and I do not remember having those problems. Violentmonkey seems to be working fine too.

blob8108

bharvey wrote:
I hate Mozilla; they keep breaking things.

Ah, but do you hate Google more?

tosh · slowly becoming a grown-up adult and very confused about it

blob8108

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

tosh · slowly becoming a grown-up adult and very confused about it

cycomachead

blob8108 wrote:
(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

cycomachead wrote:
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.

Scratch works around that by not having global blocks.

It's kinda stupid…

!

bharvey

djdolphin wrote:
Scratch works around that by not having global blocks.

Yes, exactly – it's not an option for us to do it their way.

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

bharvey wrote:
djdolphin wrote:
Scratch works around that by not having global blocks.
Yes, exactly – it's not an option for us to do it their way.

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.

Tampermonkey has worked well for me. It's a pure WebExtension.

Visit the website of Andrew Sun!

bharvey

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

bharvey wrote:
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.

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

══ trans autistic lesbian enbydoggirls // 16 17 18 19 20, she/they ════
sparrows one word to the paragraph // <3 // ~(quasar) nebula

bobbybee

_nix wrote:
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

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

bharvey wrote:
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!

Yeah, but if it's doing RGB approximations of HSV 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?)

bharvey wrote:
…is prejudiced against orange.

I noticed that thisandagain, one of the developers of Scratch 3.0, just loved a project called “Stop Prejudice”

Last edited by _nix (Oct. 2, 2017 16:28:24)

══ trans autistic lesbian enbydoggirls // 16 17 18 19 20, she/they ════
sparrows one word to the paragraph // <3 // ~(quasar) nebula

bharvey

_nix wrote:
Yeah, but if it's doing RGB approximations of HSV 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, 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

Yeah, I wasn't being very clear; sorry. I expect something like this is happening..

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

bharvey wrote:
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, she/they ════
sparrows one word to the paragraph // <3 // ~(quasar) nebula

bharvey

_nix wrote:
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.

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!

Last edited by bharvey (Oct. 3, 2017 15:11:43)

bharvey

@birdoftheday: Can you read this one?

birdoftheday

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

birdoftheday wrote:
Your new icon? Yes. What's it from?

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.

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

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.

Last edited by bharvey (Oct. 15, 2017 00:24:48)

_nix

bharvey wrote:
Edit: Jens thinks this is a typo and it was actually 126K in August, based on earlier reports.

Still, that's a pretty big bunch of new people!

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, she/they ════
sparrows one word to the paragraph // <3 // ~(quasar) nebula

Discuss Scratch