Discuss Scratch

bharvey
Scratcher
1000+ posts

Snap! user discussion

_nix wrote:

The help page just wasn't updated.
Oops that would be my fault. Sorry…

Hexwalker
New to Scratch
2 posts

Snap! user discussion

Got it! Thanks!
Dale_Mahalko
New to Scratch
68 posts

Snap! user discussion

Apparently there is a problem with turning Retina display mode on an off. It causes the images in the stage to shrink, and for sprites to become blurry, and they keep getting lower and lower resolution every time you check and uncheck retina mode, until it's an illegible mess.

Also I have no idea what Retina is supposed to mean. I just know that if I zoom in using Chrome on Windows 7 / Windows 10 to 150% or so, all the blocks become fuzzy and hard to read, so I have to enable Retina mode.

Jens
Scratcher
100+ posts

Snap! user discussion

Yeah, unfortunately supporting device pixel ratios other than 1 (which is what we call “retina support”) is a mess in HTML5 and largely beyond our control. I'm considering not letting users change the automatic setting by taking it out of the menu (or at least hiding it) altogether.
bharvey
Scratcher
1000+ posts

Snap! user discussion

Jens wrote:

I'm considering not letting users change the automatic setting by taking it out of the menu (or at least hiding it) altogether.
NOOOOOOOOOO nononononononononononononononono!

But it would be quite wonderful if instead you made the menu item a real preference instead of something doing double duty as preference plus indication of whether or not you're in fact on a retina display.

P.S. Wait, retina pixels aren't square? I never understood that; I thought they were just half-size in both dimensions.

Last edited by bharvey (Oct. 4, 2017 12:30:46)


_nix
Scratcher
1000+ posts

Snap! user discussion

bharvey wrote:

P.S. Wait, retina pixels aren't square? I never understood that; I thought they were just half-size in both dimensions.
As far as JavaScript is concerned, “device pixel ratio” isn't the ratio of pixel width to height, it's the ratio of a “CSS pixel”'s size (which is the size you have a character is styled to be “1px” tall; it's a single CSS pixel unit) to a “device pixel”'s size (which is the physical pixel on the screen).

(Edit: see also the documentation for devicePixelRatio.)

Last edited by _nix (Oct. 4, 2017 12:37:34)


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

Snap! user discussion

_nix wrote:

As far as JavaScript is concerned, “device pixel ratio” isn't the ratio of pixel width to height, it's the ratio of a “CSS pixel”'s size (which is the size you have a character is styled to be “1px” tall; it's a single CSS pixel unit) to a “device pixel”'s size (which is the physical pixel on the screen).
Ah, okay, I get it. I'm just accustomed to sentences with both “device” and “pixel” in the same sentence to be talking about non-square aspect ratios, from the early days of PC monitors having weird ratios.

Dale_Mahalko
New to Scratch
68 posts

Snap! user discussion

When storing a huge number of data values as separate lists, is there some way to vertically align the cells between each list?

With the proportional font used for cell content, the varying cell widths is ugly and rapidly becomes hard to follow due to the misaligned data cells.

A partial solution I have found that works is using spaces in front of data values and leading zeroes, for “010” rather than “10”….. Snap ignores leading spaces and does math correctly even with this cell padding.

https://imgur.com/a/W6S9x

But there is still a few pixels difference in cell spacing which will eventually go off the rails and become a mess.

,

Yes I am aware of indexing and offsets within a single list, and using lists within lists.

I am looking for an easy beginner intro to lists working at the 1st depth level only, and separate lists for each data type.

(It would be nice to have the option of a monospaced font in variables, in the options menu.)
Dale_Mahalko
New to Scratch
68 posts

Snap! user discussion

Also, when working with lists and there is a huge collection of data values that I am manually entering by hand, for things such as object coordinates in a game, how do insert a new cell to the LEFT of the existing cells already filled with data?

So far, I know of no way to do this, so if I have entered 100 data values into a list the scripting window, and I want to add a new value at the front (left side) of the list, I apparently have to manually copy and paste all cell values to shift everything right by one value. This is extremely slow and annoying.
Dale_Mahalko
New to Scratch
68 posts

Snap! user discussion

Well, there is one workaround to allow manually inserting new data into a list, by putting each data value that is to be in the list, into a separate “Insert ( ) at ( )” block.

This is not exactly compact, and doesn't really seem like the best solution. It is huge and ugly.

https://imgur.com/P4fO7hM

Last edited by Dale_Mahalko (Oct. 6, 2017 19:25:31)

bharvey
Scratcher
1000+ posts

Snap! user discussion

It's good that you included the pictures, because at first I thought you were talking about the display of lists, e.g., in a watcher.

I can't say that aligning the fields in LIST blocks is a big priority. But I think you can tell your browser to override Snap!'s font selection and use a monospace font instead, if it's important to you.

I, too, have wanted to insert new values other than at the end of a variadic input, and I agree that it's a pain, and prone to error. I suppose the way to fix it would be a right-click menu option “insert new input slot right here” (and another for “delete this input slot”). I don't know if that's even possible in Morphic – well, I'm sure the delete one would be possible, but I'm not sure about insert, because the relevant morph is the entire LIST block.

There's a more fundamental design question, though, which is whether we want to hair up context menus for relatively rare situations. I guess our general solution involves shift-right-clicking. This is the sort of thing that Jens hates to think about, but, having had the same problem, I'm sympathetic with this request.

cycomachead
Scratcher
100+ posts

Snap! user discussion

bharvey wrote:

Jens wrote:

I'm considering not letting users change the automatic setting by taking it out of the menu (or at least hiding it) altogether.
NOOOOOOOOOO nononononononononononononononono!

Your problems with retina displays aren't with the retina mode, they're other quirks that should be fixed.

bharvey wrote:

There's a more fundamental design question, though, which is whether we want to hair up context menus for relatively rare situations. I guess our general solution involves shift-right-clicking. This is the sort of thing that Jens hates to think about, but, having had the same problem, I'm sympathetic with this request.

This is the type of thing that is imperative to think about! Why? It's one of the areas where visual programming is SIGNIFICANTLY more cumbersome, AND error prone than editing text.

I'm not sure I have a good solution other than context menus, but one possible idea would be to allow drag and drop reordering of list inputs. (dragging away to delete, and dragging a block in could insert is as a list item.) You could re-shuffle blank slots, which is more work than a context menu, but DnD is a more intuitive operation. The complicating factor is that it would make it quite difficult to drag a list block around. I'm sure there are other ideas though.
SimpleScratch
Scratcher
500+ posts

Snap! user discussion

This is the type of thing that is imperative to think about! Why? It's one of the areas where visual programming is SIGNIFICANTLY more cumbersome, AND error prone than editing text.

+1

I've been wishing for some method to insert/delete slots in GP as well so its a generic issue to all block programming developments of Scratch

Simon



xly
Scratcher
100+ posts

Snap! user discussion

Dale_Mahalko wrote:

Well, there is one workaround to allow manually inserting new data into a list, by putting each data value that is to be in the list, into a separate “Insert ( ) at ( )” block.

This is not exactly compact, and doesn't really seem like the best solution. It is huge and ugly.

https://imgur.com/P4fO7hM

In Snap! there is a way to import a text file from outside into a snap! list. You need to play with Operators text blocks
It is a good programming exercise
Like in this following example where the 140 JS referenced colors have been imported into “linew”

http://snap.berkeley.edu/snapsource/snap.html#present:Username=xleroy&ProjectName=111-jscolpicker

In addition I recommend you the excellent Tutorial of Jens : “Exploring Tables with Snap!”
bharvey
Scratcher
1000+ posts

Snap! user discussion

xly wrote:

In Snap! there is a way to import a text file from outside into a snap! list.
That's a good solution for hundreds or thousands of items, but if you make

as part of a procedure and then think “Drat! I forgot indigo again!” you're not going to export, edit, and re-import the list.

bdilloughery
New to Scratch
3 posts

Snap! user discussion

I am a teacher and we use Snap! for a quarter. For two years, many of the projects work fine when the students are working on them and running them. However when they submit their shared URL and I run it, they are SUPER choppy. No matter which computer or browser I seem to try, they are choppy.

Does anyone know why this is? Is there a way to minimize/reduce this?

Thank you,
Brendan
bharvey
Scratcher
1000+ posts

Snap! user discussion

bdilloughery wrote:

However when they submit their shared URL and I run it, they are SUPER choppy.
Are you by any chance reviewing several student projects in different browser tabs at the same time? Because of Snap!'s always-live nature, I've found that running several copies at once slows my computer, even if most of them “aren't doing anything.”

Jens
Scratcher
100+ posts

Snap! user discussion

So strange! Maybe they are using color collision detection a lot? In this case running the projects in presentation mode can slow them down…
bdilloughery
New to Scratch
3 posts

Snap! user discussion

bharvey wrote:

bdilloughery wrote:

However when they submit their shared URL and I run it, they are SUPER choppy.
Are you by any chance reviewing several student projects in different browser tabs at the same time? Because of Snap!'s always-live nature, I've found that running several copies at once slows my computer, even if most of them “aren't doing anything.”

No, I mean I have done that. But I'm talking about running pretty basic projects by themselves in their own tab. I mean I have a normal 3-5 tabs of misc open that don't affect any other browsing experience (excel sheet of projects, school gradebook, gmail, etc). This is always on going. Just this morning with pretty simple hangman games that had moving sprites as background was SUPER choppy. This has been the case with most every project students turn in.

Is there any other common thing that I could tell them to avoid other than color detection? However, in hangman that was definitely not happening.
bharvey
Scratcher
1000+ posts

Snap! user discussion

bdilloughery wrote:

This has been the case with most every project students turn in.
This definitely sounds like something wrong with your computer setup. You say you've tried multiple computers. Are those school computers? When you try this, are you logged in as yourself? Could there be something about your user profile that's different from the students' that might cause this? What happens if you try it from home? (I'm always suspicious of school IT setups.)

Powered by DjangoBB