Snap! Team development discussion, vol. 2

bharvey

birdoftheday wrote:
Nosotros = subject
Nos = object

Oh, so not at all parallel to the French case. But “otros” by itself does mean “others,” so I really want to understand what possible etymology would lead to those two pronouns.

Edit: Huh. According to the Internet, “nous autres” does exist in French (although, according to one source, not in Parisian French, but neither does “vous autres” this person says). I definitely was taught “vous autres” in high school, including the fact that it has a derogatory connotation. I was not taught “nous autres,” I'm almost certain. The Internet says “nous autres” has a similar connotation but backwards: “We, who are better than the rest of you…” Everyone agrees that the cognate Spanish pronouns do not have that connotation.

Language is weird.

Last edited by bharvey (Feb. 11, 2018 04:32:58)

_nix

A new vector paint editor was added, courtesy of bromagosa. A ton of Scratch users prefer making art with the vector editor so I figure this is a pretty cool new feature

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

bharvey

_nix wrote:
A new vector paint editor was added

… in the dev version.

Hardmath123

Aw man, are we approaching the point where d(Hardmath123 code in Snap!)/d(commit) goes negative?

Is the beard new?

bharvey

Hardmath123 wrote:
Aw man, are we approaching the point where d(Hardmath123 code in Snap!)/d(commit) goes negative?

Well, when was the last time you made a PR?

Is the beard new?

Yeah. But you saw it just in time – my son unearthed this ca. 1969 photo from the basement.

djdolphin

I've restarted work on my Snap! UI mod for smartphones. It still needs a lot of work, but it's actually pretty usable now.

Screenshots: scripts tab, scripts tab with palette open, stage tab, sprites tab
Code: https://github.com/djsrv/snap-mobile-ui

My reason for wanting this is that the options for creating things on phones instead of consuming them are currently pretty pitiful, particularly on iPhones. A web-based programming language like Snap! could completely circumvent Apple's awful App Store policies, especially with the progressive web app improvements coming to iOS 11.3.

A couple design questions:

1. I want to have some way to indicate what sprite the user is currently editing since the sprite corral and sprite bar aren't visible most of the time. Scratch has this in the top right corner, but I feel like it would probably take up too much space on a phone screen:

Anyone have suggestions for that?

2. Should tapping on a script automatically switch the view to the stage tab (so the user can see the result) or stay on the scripts tab?

!

Jens

Wow, your phone UI mod is actually both beautiful and amazing, djdolphin! I love the screenshots, this is excellent work.

djdolphin

Jens wrote:
Wow, your phone UI mod is actually both beautiful and amazing, djdolphin! I love the screenshots, this is excellent work.

Thanks! The design is roughly based on fezzinate's mobile Scratch mockup, or at least what I remember it looking like. Unfortunately it seems to have succumbed to link rot: https://scratch.mit.edu/discuss/topic/50912/

!

djdolphin

I just noticed that Birdbrain Technologies' Snap! app for the iPad was removed from the App Store, and there's a different app called BirdBlox in its place. The copy I had on my iPad won't open anymore.

What was the reason for that?

!

bharvey

Jens wrote:
Wow, your phone UI mod is actually both beautiful and amazing, djdolphin! I love the screenshots, this is excellent work.

Me too. When do you think it'll be pullable?

bharvey

djdolphin wrote:
I just noticed that Birdbrain Technologies' Snap! app for the iPad was removed from the App Store, and there's a different app called BirdBlox in its place. The copy I had on my iPad won't open anymore.

What was the reason for that?

I'm guessing from the name that their new version is based on NetsBlox rather than directly on Snap!.

bharvey

djdolphin wrote:
A couple design questions:

1.

If you refrain from displaying X and Y, that reclaims quite a bit of space. Alternatively, turn some button somewhere into a picture of the sprite, or put just its name on the top or bottom of the screen, or if we're talking about the stage view, put a halo around the selected sprite, maybe even if it's invisible, but that has to be a selectable mode.

2. Should tapping on a script automatically switch the view to the stage tab (so the user can see the result) or stay on the scripts tab?

Maybe long press switches to the stage? (And the script doesn't start until the switch happens.)

PS It was really clever putting the sprite information area that's normally above the scripting area above the sprite corral instead.

Last edited by bharvey (March 21, 2018 23:54:15)

djdolphin

bharvey wrote:
When do you think it'll be pullable?

Not sure. It'll take a while to make every part of the app usable, and I'd like to add better support for touch gestures.

Code organization would also have to be figured out. Right now I have the mobile UI code in a subclass of IDE_Morph, but if it's going to be pulled into Snap! it might be a good idea to integrate that directly into IDE_Morph and have it decide which style to use based on screen size. Either that, or have two separate Snap! pages—one for desktop and one for mobile.

There's also the question of how to handle tablets, which are sort of halfway between PCs and phones. The desktop UI is usable on them, but it could be better.

bharvey wrote:
I'm guessing from the name that their new version is based on NetsBlox rather than directly on Snap!.

It doesn't seem to be based on Snap! codebase at all though. It has a different UI and a subset of the blocks.

!

bharvey

djdolphin wrote:
It has a different UI and a subset of the blocks.

It has modes. They start you off with a tiny set of primitives and work you up to the whole thing. (But you can ask for the whole thing right away, I forget how.)

djdolphin

I've hunted down the BirdBlox source code, and it doesn't use any Snap! code.

!

cycomachead

Wow, that's pretty impressive that they re-implemented most of Snap!, though at the same time quite sad.

Jonathan50

I guess it's because the App Store ToS conflict with the GNU (A)GPL?

Not yet a Knight of the Mu Calculus.

cycomachead

Jonathan50 wrote:
I guess it's because the App Store ToS conflict with the GNU (A)GPL?

I don't think so. Or at the very least I hope that's not it! For one thing, we know the BirdBrain team and would have been happy to work with them. But also, my understanding is that the GPL doesn't prevent you from distributing an app on the app store as long as you provide the source, which has always been true of the BirdBrain stuff.

Jonathan50

cycomachead wrote:
I don't think so. Or at the very least I hope that's not it! For one thing, we know the BirdBrain team and would have been happy to work with them. But also, my understanding is that the GPL doesn't prevent you from distributing an app on the app store as long as you provide the source, which has always been true of the BirdBrain stuff.

This is what the FSF said: https://www.fsf.org/blogs/licensing/more-about-the-app-store-gpl-enforcement
Also, you'd probably have to get permission from every contributor to Snap! before licensing it under something other than the AGPL (not that they would mind.)

Last edited by Jonathan50 (March 23, 2018 04:52:56)

Not yet a Knight of the Mu Calculus.

cycomachead

djdolphin wrote:
bharvey wrote:
When do you think it'll be pullable?
Not sure. It'll take a while to make every part of the app usable, and I'd like to add better support for touch gestures.

Code organization would also have to be figured out. Right now I have the mobile UI code in a subclass of IDE_Morph, but if it's going to be pulled into Snap! it might be a good idea to integrate that directly into IDE_Morph and have it decide which style to use based on screen size. Either that, or have two separate Snap! pages—one for desktop and one for mobile.

There's also the question of how to handle tablets, which are sort of halfway between PCs and phones. The desktop UI is usable on them, but it could be better.

I haven't played with your changes yet but they look great!

I would be super excited to see this work make it into Snap!. We need a mobile view. I die a little whenever I open Snap! on my phone.

In my experience with large refactors, it's better to start merging things in small bits and then enable the whole feature when it's ready. We've already got conditional drawing for flat mode, though I think there's probably a better code organization than just adding conditionals.

Whenever you feel ready, I'd say make a PR to start discussion, and try by seeing if you can make 1 PR that's only part of the mobile view, maybe enabled by an experimental setting. Then we can have a good place to discuss code mechanics.

Discuss Scratch