Script Pics too Large

[maryfries]

Two BJC developers with new and newish MBPs have the script pics coming out larger than ever, and it's too large for the curricular materials even at zoom 1x.

Is this a retina display issue?

A great workaround would be allowing for <1x zoom. It's tough to resize them consistently with HTML/CSS.

Would this is possible easily/quickly? Thanks!

[brianharvey]

Yes, it's a retina display issue. A simple workaround is to uncheck "retina display support" near the top of the settings menu, but alas you have to uncheck it every time you start Snap! or load a new project because someone who shall remain nameless won't make it possible to disable retina support on a permanent per-user basis.

[cycomachead]

A great workaround would be allowing for <1x zoom.

This shouldn't be too hard, though Jens has been really busy so I don't think a new release will happen for a little while.

[brianharvey]

We already have a workaround. What we need is a correct permanent solution, namely allowing users to turn off retina support permanently.

[jmoenig]

turning off retina support permanently is not a solution, because it will result in ... retina permanently being turned off, and Snap being illegible on HD monitors again. The right solution would be to have more control over how canvas pics can be exported, i.e. control over dpi etc. Did I mention web programming sucks?

[brianharvey]

No, no, I mean letting a user decide, not removing the feature! The checkbox should be remembered like "long input dialog" etc., and actual retina support should be determined by (checkbox AND on-retina-display).

[towerofnix]

I agree with both Brian and Jens here.

The right solution would be to have more control over how canvas pics can be exported, i.e. control over dpi etc.

This, because frequently I prefer to have retina support enabled on my Retina laptop, but I'd like to be able to export screenshots in normal-DPI (no retina), since those are generally more useful for embedding online.

And..

The checkbox should be remembered like "long input dialog" etc., and actual retina support should be determined by (checkbox AND on-retina-display).

This, because it's a user preference that I think should be kept upon refresh. Suppose you've created a browser stylesheet that makes webpages dark themed — you wouldn't want to have to re-enable that every time you open your web browser!

[cycomachead]

I suppose i'd be OK with a shift-click / hidden setting, but I don't want this to become one of those settings that people just recommend changing without understanding why.

[towerofnix]

Better: a not hidden setting? A setting including a useful information bubble, or a dialog box, so that people will understand why..

[brianharvey]

@cycomachead Why have a settings menu at all if you don't trust users to set them?

And also, the current state of things is really quite weird for a setting. It only exists sometimes, because it's half a setting and half a hardware capability flag. That's a silly saving of one bit of memory. The hardware capability flag shouldn't be controllable by the user at all. And the user preference flag shouldn't depend on the hardware capability! They are straightfowardly orthogonal. "I have a retina display" vs. "If I have a retina display, I want to take advantage of it in Snap!."

I mean, Michael, you are personally acquainted with at least one person who knows exactly what the flag means, and who every single goddamn time he starts Snap! forgets that he has to turn it off again, and finally does so after wasting a lot of time, cursing Jens every time. :(

[cycomachead]

Why do you turn it off all the time?

And I don't normally try to take the position of designer knows best type views but the problem here is the saving images not the retina capability.

And I don't trust users, namely teachers And hot shot students which often perpetuate ideas that X Y or Z are better without actually understanding implications. The display of Snap is so bad on a Retina display without retina support - I don't want this to become a thing that people just leave off all the time.

As far as whether or not showing the setting makes sense - it's weird to have a setting that does nothing. We don't store settings on a user level, only a browser level, so it makes sense to only present it when it's possible to set. There are very few cases where you would have a situation where you're doing to need to unset the Retina display setting when it wouldn't be shown.

FWIW, I think fixing the exporting of screenshots is worth it, even if a bit annoying to figure out how to do. OTOH, I recommended the zoom thing because the optimal setting for readability seems to be somewhere around 1.1-1.2x exporting, so someone trying to export block images to be read would need to adjust zoom blocks anyway. If you're going to set that value, then it seems easiest in some respects to just a one setting.

-- Michael Ball From my iPhone michaelball.co

On May 25, 2017, at 7:39 PM, Brian Harvey notifications@github.com wrote:

@cycomachead Why have a settings menu at all if you don't trust users to set them?

And also, the current state of things is really quite weird for a setting. It only exists sometimes, because it's half a setting and half a hardware capability flag. That's a silly saving of one bit of memory. The hardware capability flag shouldn't be controllable by the user at all. And the user preference flag shouldn't depend on the hardware capability! They are straightfowardly orthogonal. "I have a retina display" vs. "If I have a retina display, I want to take advantage of it in Snap!."

I mean, Michael, you are personally acquainted with at least one person who knows exactly what the flag means, and who every single goddamn time he starts Snap! forgets that he has to turn it off again, and finally does so after wasting a lot of time, cursing Jens every time. :(

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[cycomachead]

In other words, I'm not disagreeing there's s problem. I'm just saying I'm worried about adverse consequences of the proposed solution.

-- Michael Ball From my iPhone michaelball.co

On May 25, 2017, at 7:39 PM, Brian Harvey notifications@github.com wrote:

@cycomachead Why have a settings menu at all if you don't trust users to set them?

And also, the current state of things is really quite weird for a setting. It only exists sometimes, because it's half a setting and half a hardware capability flag. That's a silly saving of one bit of memory. The hardware capability flag shouldn't be controllable by the user at all. And the user preference flag shouldn't depend on the hardware capability! They are straightfowardly orthogonal. "I have a retina display" vs. "If I have a retina display, I want to take advantage of it in Snap!."

I mean, Michael, you are personally acquainted with at least one person who knows exactly what the flag means, and who every single goddamn time he starts Snap! forgets that he has to turn it off again, and finally does so after wasting a lot of time, cursing Jens every time. :(

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[brianharvey]

And I don't trust users, namely teachers And hot shot students which often perpetuate ideas that X Y or Z are better without actually understanding implications. The display of Snap is so bad on a Retina display without retina support - I don't want this to become a thing that people just leave off all the time.

This is perverse. If people leave it off all the time, it's because they have a reason! Who are you, or I, or Jens, to tell them their reason is wrong? You are totally welcome to embrace retina support when you run Snap!.

Yeah, if the script pic problem is solved, that'll eliminate one reason why people might turn it off. Another widely applicable reason is that someone is doing compute-intensive things and doesn't want a factor-of-four slowdown in the display support. Another not-so-widely applicable reason is that for whatever reasons someone is still running Firefox 31.0, which has a bug that crashes Snap! when you make the stage smaller with retina enabled.

If there's anything we should punish people for choosing by making them re-enable it all the time, it's stupid flat design. Talk about making Snap! look hideous.

P.S. Settings per browser rather than per user is a bug that should be fixed in the back end redesign.

[cycomachead]

Since we do already have the setting, I concede that it should do the right thing. However, I think the real solution make sure there's no need for someone to change such a setting.

This is perverse. If people leave it off all the time, it's because they have a reason! Who are you, or I, or Jens, to tell them their reason is wrong?

We (though, mostly Jens) have collectively over the years made thousands of decisions for users. Every application does. There are so many settings we could expose to users that would be different than our defaults. Everything from more control over looks, to the display/use of coordinates, the default set of blocks and things like how our lists are implements. We could have hundreds of settings that still allow Snap! to work the same way, but we don't expose them to users for dozens of different reasons.

Another widely applicable reason is that someone is doing compute-intensive things and doesn't want a factor-of-four slowdown in the display support. Another not-so-widely applicable reason is that for whatever reasons someone is still running Firefox 31.0, which has a bug that crashes Snap! when you make the stage smaller with retina enabled.

OK, performance debates are probably 90% of the reason why I think settings like this cause problems. It doesn't take long for this to turn into "Snap! is faster if you make it ugly". Programmers (as a whole, especially new ones--and I'm definitely including myself!) are not good about making judgements about when performance really matters or what is affecting performance. In most cases, it's not the drawing that's slowing down people's programs - or it's not as significant as other factors in code. Obviously, not every case and on particularly older or low memory devices things are a bit different. There are so many times I've heard from people in CS10 that say things like "I heard using X block wasn't good because it was slow" or "I took this (weird and convoluted) path because it was faster", and more generally the age old "recursion is slower" debate (which happens less so w/ BJC students, but I think illustrates how bad programmers are with performance and synthetic benchmarks.)

However, if we know all these places where retina mode is not as good, then we should just disable retina mode, and fix the bugs we find. Introducing a setting means that we expect users to be able to find, use, and understand what the setting does (and in the case of pref) how such things are actually connected. Otherwise, we just introduce confusion because people make decisions based on incomplete information.

Aside from the resulting bugs/misfeatures, I do agree there is a potential performance penalty in some cases. However, I don't think it applies in the vast vast majority of cases. If there is such a widespread use then I think we'd do better than just a setting that we put onto users - and if so that seems like it's a project level setting and not necessarily a user one. (Whereas the other issues are clearly user/browser level issues).

We've had numerous discussions over the years about reducing the number of settings necessary - and that's mostly what I'm trying to argue. Adding a setting is easy. But it doesn't solve the actual problem(s).

[brianharvey]

Okay, I concede that there are lots of settings we don't have, and that we don't want every imaginable setting.

Luckily, we have the JSFunction block. So I propose that whenever you start Snap! it should look for a project named Startup in your localstore, and if found, it should run (i.e. load and click green flag) it. Then I can make one that replaces the code that tests for having a retina display with "return False" and we'll all be happy. (This is one of my perennial proposals that Jens hates.)

[cycomachead]

I guess I should soften my stance a bit because my point is that if this is big problem we should fix it for everyone.

Anyway, that last comment gave me a similar idea. can't you set a userscript with JS that loads before Snap! finishes loading? Create a function that will be executed after Snap! Loads that turns the setting off so sets some property that makes Snap! think it won't work on a Retina display. Not quite a easy though, but I think possible to achieve what you want.

-- Michael Ball From my iPhone michaelball.co

On May 26, 2017, at 11:43 AM, Brian Harvey notifications@github.com wrote:

Okay, I concede that there are lots of settings we don't have, and that we don't want every imaginable setting.

Luckily, we have the JSFunction block. So I propose that whenever you start Snap! it should look for a project named Startup in your localstore, and if found, it should run (i.e. load and click green flag) it. Then I can make one that replaces the code that tests for having a retina display with "return False" and we'll all be happy. (This is one of my perennial proposals that Jens hates.)

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[brianharvey]

Yes, sure, but how do I get that script to run? Having to remember to run it by hand every time is just as bad as having to remember to turn off retina support every time.

[towerofnix]

It could be run via a normal browser userscript extension (bonus points, then, because the userscript becomes portable – that is, you could give the userscript to anybody else).

I like the idea of automatically running a Snap! project given a magic name, but if its only (possible) purpose is to modify things via the JS Function block, I think it may as well be a userscript.

[jmoenig]

This reminds me that we need to address a grave security issue with JS functions. The only way to really solve this is to disable JS altogether...

[cycomachead]

This reminds me that we need to address a grave security issue with JS functions. The only way to really solve this is to disable JS altogether...

We should move this to another thread.

[cycomachead]

@brianharvey Look at "Tapermonkey" which should be available for almost all browsers that will run your own JS on every page load (or only the domains you set).

[brianharvey]

Oh. I have greasemonkey on my Firefox. But sometimes I log in at someone else's house, or at school, etc., where I'm not allowed to install such things. So I want it associated with my username, not my browser.

[cycomachead]

So I want it associated with my username, not my browser.

OK, yeah, but until we change the cloud backend all of that isn't possible - and that goes the same with any other browser settings that one might have.

[maryfries]

I can't figure out how to turn off retina display support any more. Is the setting gone or renamed? Or am I just having a "Friday moment"?

Also, commenting is looking weird for me now, the font is slightly different in different comments. Anyone else? I'm assuming this is related, but if not, LMK, and I'll start a separate issue.

Thanks all! :)

[jmoenig]

Hi Mary, you only see the retina support menu items in situations where retina is available. If you're not seeing it that means it's not there and also not active. This can also happen on laptops with a retina monitor in certain situations, e.g. when connected to a non-retina external display or projector. Make sense?

[jmoenig]

the fonts look okay to me, the comment on the bottom might just come out a little blurry - often a retina machine trying to display in non-retina resolution looks worse than native non-retina machines.

[cycomachead]

Side note - I'm also running into this when using the autograder on a retina machine. I'm dynamically interesting script pics into the feedback - which means I don't have the option of resizing things.

In my case, I can work around it with some CSS, but I'd really like to be able to just call scriptPicNonRetina() or something....