Scratch

Jens wrote:

But there are things which are way more pressing to implement.

Indeed, in some ways we haven't gotten to Scratch-level completion.  I didn't at all mean to suggest otherwise.

joefarebrother wrote:

What if you could pan around the view of the infinite stage?

Are you familiar with Alice?  It's the main competition to Scratch.  Its big supposed feature is that it's 3-D, so you can make cooler animations.  But the Scratch Team deliberately chose to make the Scratch stage 2-D to avoid one of the huge problems with Alice:  You write a program, you run it, nothing happens at all, and you spend days banging your head against the wall until someone reminds you to check the camera angle; the program was really correct all along except that all the action is happening offstage.

I think your suggestion would give rise to the same problem.  The point of window mode isn't to make enormous pictures and then scroll around in them, but rather to allow the occasional, temporary disappearance of a sprite offstage without making the rest of the animation fail.

joefarebrother wrote:

bharvey wrote:

I think your suggestion would give rise to the same problem.

well there could be a small arrow to remind you that there are some sprites offstage, and you can disable theese arrows later but they are there by default whenever there is a sprite offstage. Also if you think memory would be an issue, there could be SOME limit to how far you can scroll (maybe you could event set this limit yourself, with an absolute limit of how high you can set the limit).

bharvey wrote:

The point of window mode isn't to make enormous pictures and then scroll around in them

Well it could be not just for pictures but also for side scrolling games!

This can already be easily done by programming solutions with Scratch. Many examples of this can be found on the Scratch site. I've already given some examples of "strategy games" where you need to move many units on a map 4 times larger that the window screen. It works fine.

joefarebrother wrote:

What if you could pan around the view of the infinite stage? There could be blocks like ...

I don't know about panning, but I'm all for a hi-res stage. 

Um, I'm developing Snap on a Mac and drag & drop works fine (mostly). I'm sure we'll get the rest to work, too 

xly wrote:

joefarebrother wrote:

bharvey wrote:

I think your suggestion would give rise to the same problem.

well there could be a small arrow to remind you that there are some sprites offstage, and you can disable theese arrows later but they are there by default whenever there is a sprite offstage. Also if you think memory would be an issue, there could be SOME limit to how far you can scroll (maybe you could event set this limit yourself, with an absolute limit of how high you can set the limit).

bharvey wrote:

The point of window mode isn't to make enormous pictures and then scroll around in them

Well it could be not just for pictures but also for side scrolling games!

This can already be easily done by programming solutions with Scratch. Many examples of this can be found on the Scratch site. I've already given some examples of "strategy games" where you need to move many units on a map 4 times larger that the window screen. It works fine.

well it is SO annoying when your making a picture using the pen and the picture is too big so you can't see it all.

in Safari importing local files via drag & drop doesn't yet work, but importing images from other web pages does. Try Chrome or Firefox! (and, BTW, wait until tonight, then costumes and backgrounds will actually do something) 

Hardmath123 wrote:

Jens wrote:

in Safari importing local files via drag & drop doesn't yet work, but importing images from other web pages does. Try Chrome or Firefox! (and, BTW, wait until tonight, then costumes and backgrounds will actually do something) 

Nope, not working. But let me make sure I'm doing right:

Open up Snap!
Click on the costumes tab
In a new window, open a picture
Drag to the costumes panel and drop

Nothing happens. I even tried dragging the address/path. 

Yeh I tried that method in Firefox as well and it still didn't work - there must be a super secret method of doing it.

works perfectly on firefox, not working on chrome 

you may want to remove the turtle sprite on the stage, and change the blocks to say background and not costume 

i guess base64 encoding will do it with the saving?

[offtopic]
bharvey, i need some advice 
do you think it's a good idea to allow different spelling of commands in a text-IDE for scratch? dunno, it's like confusing for new scratchers to use it if the commands are like '%n of %s', but no one experienced enough really wants to write to much...
what do you think?
maybe a 'short writing mode' would go... 

Last edited by roijac (2012-03-27 08:53:27)

Jens wrote:

okay, I've updated the pre-alpha and now it almost fully supports costumes and backgrounds ("almost fully" meaning that nothing works perfectly yet    ). At the moment it's best to use Firefox, where everything works pretty much as it should right now, second best is Chrome. With Safari, only importing pictures from another website works, but only if it's just an IMG element. We'll work on that part!

Just so you don't report it: Saving/Loading of costumes doesn't work, and the costume's rotation center doesn't yet have any effect.

Enjoy!

It's really not working for me. I cleared my cache, opened up Snap!, dragged in the latest Google Doodle, and watched Safari do nothing and FireFox ask me if I want to navigate away from Snap!

Am I missing something here?! 

roijac wrote:

do you think it's a good idea to allow different spelling of commands in a text-IDE for scratch? dunno, it's like confusing for new scratchers to use it if the commands are like '%n of %s', but no one experienced enough really wants to write to much...
what do you think?

Those percent-sign format strings aren't names!  Nobody ever intended for users to see them.  The name is OF, or, if you really want the full formal name, _OF_.

You're thinking, "but what about the two LENGTH blocks?"  They have the same name, and that confuses users, but it doesn't help unconfuse the users to tell them that they have two different format strings.  (What would help would be to have only one LENGTH block, btw.)

Anyway, if this helps, what the original implementations of Logo did was to allow abbreviations but to expand them when typed.  So you'd type "FD 100" and what you'd see on the screen was "FORWARD 100."  You could do that.

blob8108 wrote:

bharvey wrote:

roijac wrote:

do you think it's a good idea to allow different spelling of commands in a text-IDE for scratch? dunno, it's like confusing for new scratchers to use it if the commands are like '%n of %s', but no one experienced enough really wants to write to much...

Those percent-sign format strings aren't names!  Nobody ever intended for users to see them.  The name is OF, or, if you really want the full formal name, _OF_.

You're thinking, "but what about the two LENGTH blocks?"  They have the same name, and that confuses users, but it doesn't help unconfuse the users to tell them that they have two different format strings.  (What would help would be to have only one LENGTH block, btw.)

As I bharvey is saying, I think, it doesn't actually matter; you can work out which block they mean based on context.

If your parser sees ([sqrt] of (10)); or ([x position] of [cat])  — it can work out which function you're referring to (in Scratch, either "computeFunction:of:" or "getAttribute:of:"), based on the arguments passed to it.

([sqrt v] of (10))

([x position v] of [cat v])

Same works for the length blocks, as bharvey pointed out — you just need to check the type of the argument.

yep- it's a common programming idom called 'overloading' - selecting which function to use based on what type of inputs are given.