# Mouse scroll detection not working

1. What browsers show this problem? Chrome
2. Please share an example project (if possible).
3. Describes the steps to reproduce this issue. Used current Scratch script for scroll detection (when up arrow pressed hat -> if(not up arrow pressed) "scroll up")
4. What does Snap! currently do? Nothing, the hat doesn't even trigger as far as I can tell.
5. What should Snap! do instead? This worked in Scratch 2 & still works in Scratch 3.0, so I feel that it should work in here. However I'm not familiar with how exactly the code runs in Scratch. I am a bit new to Snap, so if I put this in the wrong place, I am sorry and would you please direct me to the correct location? Anyone have ideas?

1 Like

OK sorry. Thank you so much. Lol I should've looked deeper. Edit: however, i still feel that the method used for scratch 2.0 and 3.0 should be added to avoid confusion and for parity. Anyone agree?

I kind of agree because of converting scratch projects to snap

In Scratch - the keypress hat block shouldn't really be responding to mouse events

But it always has so that's just the way it is

Snap! corrects this behaviour - its just one of those things that is slightly different between the two systems.

JFI, a thing that catches new AT Scratchers out is that pressing the Green Flag will not stop all running scripts before re-launching all GF hat scripts - you need to explicitly press the stop button to do that

1 Like

All this recent talk about changing Snap! in various ways to match misfeatures of Scratch is starting to make me think we shouldn't make it so easy to convert Scratch projects to Snap!. Instead we should change everything we inherited from Scratch to do it right instead. Counterclockwise from East. Stuff like that.

1 Like

Totally agree. SNAP is doing itself a disservice by trying to propagate SCRATCHNESS! !!
Computing world is full of similarly behaving languages; and their reason for existence is "why they are different", not why they are similar. There could be a simple doc that describes the differences and off they go. Besides what is the point in bringing in a Scratch pgm intro SNAP and running it. If it is something that could use the enhancements of SNAP, then it requires a re-work anyway. If it's for sharing, then share it as a Scratch pgm - we know how to run it. For the basic initial xfer there are already tools in place to address the bulk of the work. Plus I do not think that there are any Scratch opus dei that the SNAP world is missing out on.
And here is my strongest argument: propagating xfers rewards laziness and makes the SNAP newcomers think that it is all the same here - and it certainly is not! And to think so is an utmost insult to work done by Jens, Brian, the rest of the dev team.

2 Likes

https://scratch.mit.edu/projects/18997849/

Near as I can tell, the person who did this never did another project and never logged in again.

Ok, I see your point. Thinking about it this way, I agree with you. I was xferring my project into Snap for testing the key press stuff but remember how you can accomplish scroll detection in Scratch. Snap!'s way is actually much better for code readability etc. (semi-off topic question: If I wanted to help w/ making Snap! more like how Scratch was meant to be (like how its not suppose to detect mouse wheel events like that), where should I go? Is there such a place? Still very new to Snap!)

I'm not sure what you mean by "how Scratch was meant to be." But if you're new to Snap!, I think the first thing you might do is look at some of the libraries written in Snap! itself, such as the List Utilities library, the Iteration and Composition library, or the Words and Sentences library, then find something you think is missing and see if you can implement it.

1 Like

You keep talking about it. Just do it.

At this point in time, Snap!'s primitives are similar enough to Scratch's that there's no reason you shouldn't be able to open Scratch projects in Snap!. Most Scratch projects can be recreated in Snap! without changing much, if anything. The work Snapinator does is mostly a matter of converting between the relevant data structures so that kids don't have to go through the drudgery of doing it themselves.

Of course, if you want to take advantage of Snap!'s features, you're going to have to rework the project, but Scratchers are used to reworking things. Scratch's entire culture is built on allowing kids to create and remix projects, and I think there's great value in making all 60 million Scratch projects available as a base for remixes in Snap!. Maybe you haven't seen any Scratch projects you'd find worth extending with Snap! features yet, but there are 60 million Scratch projects. There's bound to be something you would find worthwhile in there.

Of course, if Snap!'s primitives were sufficient different from Scratch's, it would be a different story. But we aren't at that point yet, and we'll cross that bridge when we get there.

ok, now, I think it would be great if there was something like
[scratchblocks]
when [up arrow v] pressed or [scrolled up v] :: control hat
[/scratchblocks]

Just use a key pressed hat and when scrolled hat that trigger the same broadcast or custom block. This doesn't need its own primitive.

Well, there's the small matter of getting Jens to agree. He's much more tied to Scratch in his thinking than I am. That's why we have video capture with motion detection, for example. Also, we can't do it a little at a time, because we don't want to break our own existing projects, so we have to increment the version number in project files and continue to support the old ways when loading old projects, and Jens is right that that sort of thing leads to ugly code. And we have to coordinate with you, so that Snapinator can translate Scratch projects into the new ways of doing things. (https://en.wikipedia.org/wiki/Flag_day_(software))

There's a chicken and egg problem; you're saying when we get different enough we can worry about whether we want to get different. And you're right that I'm having trouble getting anyone, not just Jens, to entertain that idea in the abstract, but if they don't, it'll never happen.

And then there will be sub-disagreements on the details. For example, I really want to replace the existing pen color primitives with my color library (reimplemented in JS). I think Jens is quite happy to have the library, but would resist replacing the primitives with it, partly because he doesn't believe in HSL, partly because that isn't how Scratch does it, and partly because it's just more complicated. (I think it doesn't matter that it's complicated, because the complication is just while running SET PEN. Once you've done that, you have an RGB color under the hood and it doesn't slow down drawing at all.

My suggestion is to make [how the the primitives handle units] line up with how the "real world" does things wherever possible, and make all the Scratch-isms and other abstractions like crayons into library blocks. That includes directions and color. Whenever an old project with Scratch blocks is loaded, load the Scratch-isms library, and replace all the old primitives with the library blocks.

It's usually quite a bit easier to find information on how to work with real world conventions than with whatever poorly explained, magic systems the Scratch Team's decided on. Like, I think as long as there's a block to set the pen color's R, G, and B components, figuring out how to do different color systems is pretty trivial. Assuming performance isn't too big an issue, the other color systems, including Scratch's, could be implemented entirely in Snap! to act as an example of that.

Ah, no, you don't really mean that (I hope). For example, the real world doesn't do turtle graphics; they make you figure out the Cartesian (but with the Y axis upside down) coordinates of the endpoints of the line segment you want to draw. Sprites, costumes, all those things are abstractions built on top of real world capabilities.

The question is, what abstractions make it easiest for a learner to express their goals with a minimum of arcane incantations.

Actually, even the real world uses abstractions. For example, take crayons. The real world uses crayons! You can say "color:powderblue" and get b0e0e6. And my color library includes the X11 crayons as an option, although I like my crayon selection better because it's more evenly distributed through color space. (They have 20-odd off-white colors, for example: ghostwhite, oldlace, snow, ivory... They probably started by looking at a sampler of house paints.) Even more important, my crayon block has a two-level menu in which the colors are divided into their spectral families, so you don't have to search for the color you want.

But also, much of the time people don't care about the exact colors; they just want to be able to say change color by 1 and get a more or less continuous gradation of interesting colors. That was a good abstraction in Scratch, which they've moved away from by making the HSV scales explicit. (The old way did have the misfeature of getting trapped in black.) My default color scale restores the one-dimensional scheme while avoiding the black hole and including shades of the spectral colors.

Now, there's plenty of room for argument about whether the abstractions I've chosen are the best possible. But certainly RGB isn't the best answer! And HSV is probably the worst possible because of its asymmetrical treatment of tints and shades. I would love to have the argument with people interested in colors, and maybe you could convince me, for example, that we should use the X11 crayons rather than mine for real-worldness.

Similarly, the real world, at least the real world of computing, doesn't use polar coordinates in graphics. They only use the upside-down Cartesian coordinates. So both the Scratch clockwise-from-north and the mathematical counterclockwise-from-east are abstractions. The original Logo approach, which Scratch inherited, was that kids intuitively see north as the "starting" direction because they see both actual compasses and the privileging of north in the compass rose on a map:

(which is that way, of course, because on a magnetic compass they paint the north-facing end of the compass red). I think that was definitely the right choice in Logo. In Scratch it's complicated, because most of their costumes, the ones representing people anyway, are vertical and facing east, so they end up giving sprites a starting direction of 90. That's a needless layer of confusion for beginners. For us, it's further complicated by the fact that our audience includes math teachers, who are adamant about ccw-from-east. Their reasons have nothing to do with what's intuitive for kids, so the question for us is whether we care enough about mathematical convention to adopt it -- well, that and the argument that costumes start out facing east.

That question, about measuring direction, is one that Jens gets angry about. He points out that it's trivial to write a library with blocks ANGLE and SET ANGLE that do ccw-from-east. And he's right. So the First Law of Engineering tells us not to change how we do it. I think if we implement student accounts and implement per-user startup libraries, I would then be totally in favor of not changing DIRECTION.

Anyway, the point of this long message is really just that you can't say "do what the real world does" in a language for learners. Otherwise we'd just teach Javascript instead, or anyway make the Snap! blocks exactly represent the JS primitives.

Oh, I do, but not in the sense of getting rid turtle graphics. That would be silly.

I mostly mean it in the context of units - a lot of primitives accept numbers, but what do they actually mean? The "real world" often doesn't agree how things should be measured (insert grumbling about the US and metric here), but I think it's important to use a method used somewhere in the real world, so that users can find some sort of information on how to work with the numbers put in front of them.

My view on Scratch directions is that putting the start direction at 90° is plain confusing. If you have a costume of something facing right, 0 = NORTH, and it makes sense, but as soon as you have a costume of anything else, that breaks down. I'm not aware of any other context where 90° means "no rotation." Whether positive means cw or ccw, I don't care so much.

The old Scratch pen colors were the worst. For one, they used (and still use) the word color instead of hue, hues ranged from 0-199 for some reason, and there were these mysterious "shades" that I still don't understand. Want to use a color picker from an "adult" program that gives you an RGB/HSV/HSL/whatever? Good luck with that.

RGB is definitely not the best abstraction for general use, but I think it should be available since it's widely used, and it's easy to find information on its relationship to better abstractions. And it would be great if the better abstractions that Snap! provides are written in Snap! itself so users can see how they work, instead of them being inaccessible magic.

One of the Scratch abstractions that upset me recently, which you've probably already seen, is pitch. First, the pitch blocks use tenths of a semitone, which is just weird, and second, they don't even make the units visible. I guess you're just supposed to type in a number that sounds good, but I'd prefer to be able to tell what's going on, and read up on how it works.

For the most part, the Snap!-specific features do a good job with this. The sound blocks are labeled with Hz, it's explained where character codes come from, the crayon names have hex codes next to them, etc. That's all good, but I think there's still room for improvement on the features inherited from Scratch.

Anyway(s), sorry for not being explicit enough in the first post, and I hope this clear up what I meant.

Oh, yes, 0-199 is weird. What's good about the (old) Scratch color abstraction is just that it's one-dimensional. You can say change color by 1 and expect something sensible to happen.

A shade is a mixture of a spectral color (hue) with black. In color transmission (monitors, as opposed to paints or dyes), that means reducing the intensity of the hue, because there's no such thing as black light to mix in. If you mix in white instead, you get a tint.

Of course RGB should be available. My set color block even accepts six hex digits! The question is, what should be the default choice when you drag the block out of the palette. Certainly not RGB, and I think not hue (our current status) either. My choice, a color scale that goes through the spectrum but also includes shades (darker versions) of the spectral colors, is admittedly three levels of abstraction up from RGB (hue, fair hue, color), but someone who cares about color in detail has a complete choice of all possible scales. The color abstraction is meant entirely for users who really don't care about the colors as long as they're different, and continuous. (That latter requirement is why crayon shouldn't be the default scale.)

(The crayon menu, by the way, should also have color samples!)

So, the meta point here is to think about whether it matters what metaphor about colors you show to users by default, given that you offer all the other possibilities too. I think it does matter. Jens, I think, thinks (at least with respect to colors) that it doesn't matter.

Whether it matters has to be settled before you start thinking about what the best choice is.

To be honest this place is slowly fading away because of Scratch, maybe Snap! should use some original features, not only just Scratch features?

I know I made some feature requests that have a Scratch feature, but that was mainly for the Costume Editor and not just because "Scratch has it" I simply just wanted a good Editor tool that can be easier for me and other young Snap! coders to make a very detailed drawing!

To be honest it kinda annoys me when people need something on a website just because another site has it, they should create their own things(The things that make them unique).

Also, if you want a feature that is only on Scratch, just go to Scratch and do the coding and stuff, and then use the Snapinator to publish your work on scratch here!
People should stop trying to make Snap! an exact copy of Scratch.

Sorry if I made my opinion a little random, but I read the conversation between @bh and @djdolphin, and I had an opinion stuck in my head that I just had to get out and tell all of you. This isn't Scratch, and Snap! shouldn't be an exact copy of Scratch....thank you for reading my comment. And please don't be mad at me for my own opinion, this didn't take forever to type just for you to get mad at me.

I know what a shade is in the abstract, but Scratch shades were just not implemented in a way where the numbers made any sense to me.

I've just looked at the source code, and I guess a shade of 0 was supposed to get you 5/6 of the way from hsv(hue, 100, 100) to black, a shade of 50 is just hsv(hue, 100, 100), and a shade of 100 was supposed to get you 5/6 of the way from hsv(hue, 100, 100) to white. Even understanding what's going on, it's just rather arbitrary.