Vee is cool.
Offline
scimonster wrote:
Vee is cool.
I like my version better than Jens's version. (He left out the scripts to add and remove vee in the list of end shapes. The way this lesson works is that you start without vee in the list, get students to understand how the procedure works, then add vee to the list and ask them to predict the results.)
PS ... except I can't get it to work in Firefox. It works in Safari and Chrome.
PPS ... even though I made the xml in Firefox to begin with!
PPPS: It works for Jens in Firefox. Firefox hates me.
P^4S: Link fixed per Jens' instructions. Thanks! (I couldn't figure out from the bit.ly links what the link actually was! So I copied it by hand from the URL bar.)
Last edited by bharvey (2012-07-04 12:00:26)
Offline
bharvey wrote:
scimonster wrote:
Vee is cool.
I like my version better than Jens's version. (He left out the scripts to add and remove vee in the list of end shapes. The way this lesson works is that you start without vee in the list, get students to understand how the procedure works, then add vee to the list and ask them to predict the results.)
PS ... except I can't get it to work in Firefox. It works in Safari and Chrome.
PPS ... even though I made the xml in Firefox to begin with!
PPPS: It works for Jens in Firefox. Firefox hates me.
Doesn't work on FireFox for me. I'm using 3.1 (!), and am surprised normal Snap! works so well.
Offline
Brian's link is wrong, it tells Snap to open an'html file instead of "vee.xml", please try the original link to Vee (the actual file is now Brian's version of Vee) and let me know if that one works in your Firefox. Thanks!
Offline
Jens wrote:
Brian's link is wrong, it tells Snap to open an'html file instead of "vee.xml", please try the original link to Vee (the actual file is now Brian's version of Vee) and let me know if that one works in your Firefox. Thanks!
Yes, the link above and in the original post now open Brian's version of vee in both Firefox and Safari.
Offline
Jens wrote:
Brian's link is wrong, it tells Snap to open an'html file instead of "vee.xml", please try the original link to Vee (the actual file is now Brian's version of Vee) and let me know if that one works in your Firefox. Thanks!
No files open on FF 3.1 (not that I expected such astonishing legacy support in the first place). Safari 5.1.7 (latest) runs perfectly. You rock, Jens!
Offline
The History.txt file, says:
120703
------
* GUI: open a project from URL via #open:URL
* GUI: run a project from data via #run:XML or from URL via #run:URL
------
What is the distinction between #open: and #run:?
When I #open a url, I see the full IDE as expected. But, when I change #open to #run, I don't see any substantive changes to the interface. I thought I might see a full screen representation of the Stage. Alternatively, does this difference simply accomodate differences in file formats?
Or after further reflection, does it open the project and then hit the green flag button? In this version of vee, the #run is very subtle because the shape list does not initially include the two vee blocks.
Just tested the latter hypothesis and observed that the terminal shapes change with most page reloads when I use #run and they are consistently square, star (over five reloads) when I use #open. I conclude that this feature is probably more applicable to other Snap! projects.
Last edited by scspaeth (2012-07-04 16:41:25)
Offline
I FINALLY FIGURED OUT HOW TO EDIT BYOB.
Now I can make pink, black, white, whatever color blocks!
Offline
Idea:
Instead of having to right click a block to see it's definition, it should show the definition in the scripting pane under a special hat block that is the block's prototype that would be collapsible so you could hide the definition but still see the block's header. This would make blocks a little more self-documenting because you could see the names of the inputs and the comments attached. This can be useful if, say, you defined your own type using data abstraction with blocks, and it was then unclear what kind of input another block you made should take, you could give the inputs meaningful names and hide the definition so a user (someone else, or you in a few months time) can see the header to see what inputs it takes, without having to concern themselves with the definition, which might be complex.
Offline
joefarebrother wrote:
Instead of having to right click a block to see it's definition, it should show the definition in the scripting pane under a special hat block that is the block's prototype that would be collapsible so you could hide the definition but still see the block's header.
This idea has come up repeatedly, and I believe they're talking about something similar for Scratch 2.0. I'm really reluctant to fill up the scripting area, even with just the hat blocks. In my Scratch experience by the time you have four scripts in there, it's really hard to keep control of the screen layout.
I'd be happier if we could invent an uncluttered way to make the formal parameters visible in the palette. So, for example, I know this isn't the right solution, but just as a starting point for discussion, imagine that a custom block in the palette looks like its prototype in the block editor, but when you drag it into the scripting area it looks the way it now looks in the palette (with empty or default-ful input slots of the right shapes). This is the wrong thing because it makes the look and feel of custom blocks very different from that of primitive blocks. But it does expose the formal parameters to the user without cluttering the scripting area.
A really simple thing to do that I don't think would hurt anything would be to have the Help menu item on a custom block generate a helpscreen with the block's prototype as (part of, maybe) its text. (It would still have the block as it appears in the palette as the heading in the top left corner.)
Offline
I like the idea of generating a human-readable (formal) explanation of custom blocks. But I'm afraid I don't get why you need to expose the names of formal parameters to the users of a custom block. The block prototype merely determines the appearance of the block instances. The beauty of Scratch is that you don't have to know about the formal parameters, because you can see the argument slots in every block. And part of the beauty of Snap! is that you can document the slot types in the long form input dialog. So, really, everything the user needs to know about using a custom block is "documented" in the appearance of its instances. Or what is it I'm not understanding here?
Last edited by Jens (2012-07-06 02:17:28)
Offline
Incidentally, I think a more practical and less obtrusive way to display the block editor would be as a separate tab (i.e. "scripts, costumes, sounds, blocks").
Offline
Jens wrote:
I like the idea of generating a human-readable (formal) explanation of custom blocks. But I'm afraid I don't get why you need to expose the names of formal parameters to the users of a custom block. The block prototype merely determines the appearance of the block instances. The beauty of Scratch is that you don't have to know about the formal parameters, because you can see the argument slots in every block. And part of the beauty of Snap! is that you can document the slot types in the long form input dialog. So, really, everything the user needs to know about using a custom block is "documented" in the appearance of its instances. Or what is it I'm not understanding here?
Well what I was thinking is that if you defined your own type via data abstraction techniques, it can sometimes be ambiguos what kind of input a block should really take. For that reason, if you could see the names of the parameters, it would be a little more self-documenting. Also, if you could see the prototype in the scripting area, users could read comments attatched to it.
Offline
joefarebrother wrote:
if you defined your own type via data abstraction techniques, it can sometimes be ambiguos what kind of input a block should really take. For that reason, if you could see the names of the parameters, it would be a little more self-documenting. Also, if you could see the prototype in the scripting area, users could read comments attatched to it.
I agree with both of you. There should be a goof way to document the domain of a block, and for custom blocks, the input shapes don't really suffice because of abstract data types. (In some of my projects, pretty much all the inputs are of type List, but in my mind there are half a dozen distinct kinds of lists.) On the other hand, the formal parameter isn't necessarily the best way to provide that documentation.
When we can attach comments to code, we should adopt the convention that a comment at the beginning of a procedure is meant as external documentation for the caller of that procedure, so when you ask for Help on the procedure, that comment should appear (along with the prototype, with its formal parameters) in the helpscreen. (These can be generated on the fly, I hope.)
I don't think the user needs to see this document about all custom blocks all the time If using helpscreens isn't good enough, I wouldn't mind a feature that when you hover over a block in the palette, it temporarily fills all the input slots with their parameters. But often the parameter isn't enough help anyway; hands up if you've never used "list" as the parameter for a list input.
Last edited by bharvey (2012-07-06 10:28:47)
Offline
shadow_7283 wrote:
Incidentally, I think a more practical and less obtrusive way to display the block editor would be as a separate tab (i.e. "scripts, costumes, sounds, blocks").
That's not a bad idea.
PS Oh, wait, you mean to do that instead of having a block editor window? I think that would be confusing, partly because by default a custom block doesn't belong to a particular sprite, like those other tab things. Also I want to be able to drag easily between the scripting area and the block editor while editing a block, and to be editing two blocks at once (but not all blocks at once), etc. But I think a tab like that could be a place to put the programming interface information that joefarebrother wants.
Last edited by bharvey (2012-07-06 11:07:55)
Offline
Jens wrote:
Hi christian2000, what you're seeing is Scratch's ASK prompter invoked from the stage, not a BYOB bug.
Well, how do i get rid of it?
Offline
Press the blue check mark button next to it.
Offline
IDEA: Build your own hat blocks! (first-class events)
Offline
joefarebrother wrote:
IDEA: Build your own hat blocks! (first-class events)
This was suggested very early for BYOB3. The way we'd do it is just to have a hat block WHEN <hexagon> in the Control palette. Jens was a little nervous about how much it might slow things down, and also there is a small question about what happens after you click the stop sign; should this condition still be checked? Or not until the user does something like click the green flag? (All the existing hat blocks are either triggered by a user action or not triggerable when all scripts are stopped.) But, yeah, we'll get to it.
Offline