Scratch

@Jens, for exporting projects, use:

if (!window.URL) {
    window.URL = window.webkitURL;
}

...

var data = <insert project data here>;
var fileName = <insert project name here>;

var bytes = new Uint8Array(data.length);

for (var i = 0; i < data.length; i++) {
    bytes[i] = data.charCodeAt(i);
}

var url = URL.createObjectURL(new Blob([bytes]));

var a = document.createElement('a');
a.href = url;
a.download = fileName;
a.type = 'application/zip';
a.onclick = function () {
    setTimeout(function () {
        URL.revokeObjectURL(url)
    }, 20);
}
a.click();

Last edited by MathWizz (2012-08-28 10:25:08)

MathWizz wrote:

Question... Why did you go with XML instead of JSON?

I chose it for a couple of reasons:
- The distinction between attributes and children makes a lot of features in a project's serialized form concise, e.g. blocks (<block s="selector">arguments…</block> vs { "type": "block", "s": "selector", "arguments": [ arguments… ] } or something similar) and expressions
- The implicit "type" (an element's tag name) makes a few things simpler (e.g. loading blocks) and makes a bunch of things shorter (e.g. <type id="id" …/> vs { "type": "type", "id": "id"… } and <ref id="id"/> vs { "type": "ref", "id": "id" })
- Fewer quotation marks   

Last edited by nXIII (2012-08-28 12:06:06)

Hardmath123 wrote:

How about the fact that Scratch 2.0 is in JSON? Not only does it mean someone probably thought it through at MIT, is also means we can compile 2.0 to Snap! (and maybe vice-versa in a future Scratch release).

The formats wouldn't be identical so we'd have to import/export anyway.

Last edited by nXIII (2012-08-28 12:30:27)

Jens... Did you see this?

MathWizz wrote:

@Jens, for exporting projects, use:

Code:

if (!window.URL) {
    window.URL = window.webkitURL;
}

...

var data = <insert project data here>;
var fileName = <insert project name here>;

var bytes = new Uint8Array(data.length);

for (var i = 0; i < data.length; i++) {
    bytes[i] = data.charCodeAt(i);
}

var url = URL.createObjectURL(new Blob([bytes]));

var a = document.createElement('a');
a.href = url;
a.download = fileName;
a.type = 'application/zip';
a.onclick = function () {
    setTimeout(function () {
        URL.revokeObjectURL(url)
    }, 20);
}
a.click();

Jens wrote:

to me an imortant benefit of XML is that it's human readable and "open" in an almost natural way, i.e. it can be understood by itself and others can easily create apps which read / write it. For example, some institutions want to evaluate students' projects in a textual form, and we can just point them to our XML format, which actually *is* a textual form. Same for people with disabilities, they can probably use an XML format much better than a cryptic JSON one. But, most important to me, our XML projects can be inspected (and edited!) in the browser and in any text editor, even without JS.

I don't find JSON any less readable than XML, if it's properly formatted (it just looks like a JS object literal with way too many quotation marks); if it's not, I agree that it's even worse than whitespace-stripped XML.

Also, you can edit JSON in any text editor (or the browser, with <textarea> and friends). You don't need JS for anything except parsing it (but you can use other things to parse it, too).

—

I was trying to name variables with Unicode characters in Snap and realized I couldn't (via copy-paste, Character Viewer, or an option-keypress), so I made a script that replaces Morphic.js's CursorMorph-based text editors with native ones. This adds support for all platform-specific input methods and keyboard shortcuts as well as copy-paste and undo. You can install it in your local copy of Snap by adding the following line:

<script src=http://dl.dropbox.com/u/10715865/Web/Snap/inject/native-editors.js></script>

Or use the following bookmarklet to use it on the hosted copy:

javascript:var d=document,s=d.createElement('script');s.src='http://dl.dropbox.com/u/10715865/Web/Snap/inject/native-editors.js';d.querySelector('head').appendChild(s)

Last edited by nXIII (2012-08-28 14:46:19)

bharvey wrote:

Ah, that's interesting.  How do I install it on my Android tablet?  And will it solve the problem of the virtual keyboard not appearing?

I'm not sure how you can install it (unless you use a local server and navigate to a local copy on your desktop).

It probably would fix the virtual keyboard not appearing, but I haven't tested it so I'm not sure.

OK, my non-determinism project works partially now.  The sprite says the first choice but then for some reason it (seems to) get stuck in an infinite loop (the script is still highlighted but it isn't doing anything). That is still better than it not working at all and just red-haloing the script with no indication of what went wrong. However, now it won't save. 

Screenshot:

PS: the input for choose is varadic, any unevaluated.

So two things: Why does it get stuck, and why won't it save?

EDIT: Now it doesn't get stuck any more, but, weirdly, it sometimes says 3 then fail, and sometimes it says 3 then 4 then causes an error. None of these were the intended behaviour, which is to say 3, then 4, then 5, then fail. It still won't save, either.

Last edited by joefarebrother (2012-08-29 07:14:52)

joefarebrother wrote:

...the input for choose is varadic, any unevaluated.
... causes an error ...

hmm., I've never even tried variadic unevaluated inputs in Snap. Maybe they plain don't work yet    did you try them on something simpler?

Well, hunting bugs means trying to spot exactly where something doesn't produce an expected result, and finding the *first* place where this happens, so we'll have to try something *simpler* not the same complex mashup with one single thing changed...

Let's try to get out of this abbreviated alarm mode and do some engineering here ... once I get back from my vacation 

Jens wrote:

Isn't this pretty much what current versions of Morphic.js already do with what I call "virtual keyboard" support? Create a HTML input element, make it transparent and relay its events to the Morphic Cursor? So we really just have to add maybe two more event bindings to the existing code to get copy/paste for free, right?

Nope. This one overlays the text editor so selection and editing are managed by the native <input>, which allows access to all platform features like:

- Correct key bindings (alt/ctrl/cmd+arrows on mac, selection with shift)
- Copy & paste (support for this isn't very good with JS events)
- Spellchecking
- Services, Look Up, Search, & Speech (OS X)
- Undo/Redo

I'm not sure if anybody has posted about this yet (sorry if it already has), but recently I just noticed this video about Snap! I thought it was pretty interesting - I'm looking foward to see how Snap! will do with supporting real world sensors and such. 

... fixed!

the zebra coloring bug in the video (and a few other minor ones, including the script-variable one that's been reported by you)