Scratch

I can't wait to see this! It will be great to make Scratch blocks downloadable in the library!

Greenatic wrote:

Dreamod, before you do the final release, do you want me to go through the library and find any other block-specific tweaks needed?

Yes, please. I was thinking the same thing.

Ok, it's probably done. I need beta testing though.

Greenatic wrote:

dreamod wrote:

Greenatic wrote:

Dreamod, before you do the final release, do you want me to go through the library and find any other block-specific tweaks needed?

Yes, please. I was thinking the same thing.

I will edit this post as I find them.
IMPORTANT:  Remember, C block methods go under Scratch-Execution Engine > ScratchProcess > private-special forms.
#1.
Blocks: #MakeDraggable: #MakeUndraggable:

Change: Go to Scratch-Blocks > SpriteArgMorph > other > presentMenu and replace it all with this:

Code:

presentMenu
    | t1 t2 t3 t4 t5 |
    (t1 _ self ownerThatIsA: ScratchFrameMorph) ifNil: [^ self].
    (owner isKindOf: CommandBlockMorph)
        ifTrue: [t2 _ owner selector].
    t3 _ t1 scratchObjects.
    t3 sort: [:t6 :t7 | t6 objName asLowercase < t7 objName asLowercase].
    t4 _ CustomMenu new.
    t2 = #getAttribute:of:
        ifTrue: [t4 add: 'Stage' localized asUTF8 action: t1 workPane]
        ifFalse:
            [(t2 = #MakeUndraggable: | t2 = #MakeDraggable:)
                ifFalse:
                    [t4 add: 'mouse-pointer' localized asUTF8 action: #mouse.
                    t2 = #touching: ifTrue: [t4 add: 'edge' localized asUTF8 action: #edge].
                    t3 _ t3 copyWithout: owner receiver]].
    t3 size > 0 ifTrue: [t4 addLine].
    t3 do: [:t8 | t4 add: t8 objName action: t8].
    (t5 _ t4 startUp) ifNil: [^ self].
    morph _ t5.
    self fixGetAttribueBlock.
    self updateLabel

#2. 
Block:  When < > is true (hat block)
Changes:  Go to ScratchFrameMorph > processWhenConditions and OffscreenWorldMorph > processWhenConditions.  Find and delete this line:

Code:

true ifTrue: [^ self]

#3.
Blocks:  Stage panning blocks.
Changes:  See this post.
#4.
List blocks.  I believe I mentioned this already.

The c blocks should be proper but I haven't tested it.
√ 1: this goes under 'moreCodes'
x 2: I'll work on this one.
√ 3: what's your problem here? I can make those blocks seperate.
√ 4: do you mean default args? I fixed that.

Greenatic wrote:

#1:  Could you explain how that would work?  I'm a little confused.  Also, the base-changing blocks require some helper methods...how would that work?
#3:  It requires multiple edits to some methods to change the attribute dropdown.
#4:  Yes, that's what I meant 

1: Well, there is a 'moreCodes' function when exporting a block. By typing 'moreCodes' after holding a modifier button on the keyboard, you can add more codes to the block file by specifying a class and selector. It can automatically detect if it's in class of instance. So, you would include the sprites menu as an extra code in the block file.

3: Did you mean the attribute menu or the panning blocks? The panning blocks can be done separately. Can't you just file-in the new methods for the attribute add-on? By file-in I mean include it in the block file (using 'moreCodes: 4' (4 needed for the attribute add-on)), which gets filed-in.

Greenatic wrote:

dreamod wrote:

Greenatic wrote:

#1:  Could you explain how that would work?  I'm a little confused.  Also, the base-changing blocks require some helper methods...how would that work?
#3:  It requires multiple edits to some methods to change the attribute dropdown.
#4:  Yes, that's what I meant 

1: Well, there is a 'moreCodes' function when exporting a block. By typing 'moreCodes' after holding a modifier button on the keyboard, you can add more codes to the block file by specifying a class and selector. It can automatically detect if it's in class of instance. So, you would include the sprites menu as an extra code in the block file.

3: Did you mean the attribute menu or the panning blocks? The panning blocks can be done separately. Can't you just file-in the new methods for the attribute add-on? By file-in I mean include it in the block file (using 'moreCodes: 4' (4 needed for the attribute add-on)), which gets filed-in.

1:  If we give it an existing method, does it overwrite it all or add it to the end?
3:  Whoops, I meant the attributes.

I know I probably sound stupid, but could you please explain how you make the block files?

1: It overwrites, but that is the only such method in the block library, isn't it?

The block files are actually relatively simply structured. It can be created in the block importer so you don't have to know any of this stuff, but here's how it works.

It has the block code, an advanced version of a block spec, and optional other codes.
the block spec is called once the block is filed-in, and then added to a dictionary called CustomBlockSpecs under 'Sprites' (or 'Stage' or 'All') and then the category.

Here is an "advanced" block spec: ('Sprites' 'control' ('command spec' #- #selector))
                          |  Sprites or Stage or All | category | block spec |
Do you know what I mean?

dreamod wrote:

LS97 wrote:

You can report your own post and ask a mod to delete it 

Thanks for the advice, I'll try that. I hate being a 'new scratcher' just because this account is new. I have a lot of experience in scratch and a decent amount of experience in squeak. Too bad people just read the 'new scratcher' and think: 'oh, just a new scratcher, his patches and blocks are probably insignificant'. But I'm sure there are also people who won't judge me by the 'new scratcher' status.

Oh, wow.  I just noticed that.

muppetds wrote:

GeonoTRON2000 wrote:

dreamod wrote:

Thanks for the advice, I'll try that. I hate being a 'new scratcher' just because this account is new. I have a lot of experience in scratch and a decent amount of experience in squeak. Too bad people just read the 'new scratcher' and think: 'oh, just a new scratcher, his patches and blocks are probably insignificant'. But I'm sure there are also people who won't judge me by the 'new scratcher' status.

Oh, wow.  I just noticed that.

I don't pay any attention to the status
i make my own opinions on scratchers based on what i read

Thank you, I respect that. Be sure to try the new patch when it comes out!

Greenatic wrote:

[
Could you give us an example of a working block file with a custom dropdown?

Ok, here is an example.

'From MIT Squeak 0.9.4 (June 1, 2003) [No updates present.] on 16 April 2012 at 5:39:08 pm'!

!ScratchSpriteMorph methodsFor: 'accessing' stamp: 'jm 12/1/2006 11:30'!
rotationStyle: aSymbol
    "Set my rotation style to #normal, #leftRight, or #none. Styles mean:
        #normal    -- smooth 360 degree rotation
        #leftRight    -- flip about the vertical axis
        #none        -- do not rotate"

    rotationStyle _ aSymbol.
    self costumeChanged.
    self positionTalkBubble.
! !
!CustomBlockSpecsDictionary class methodsFor: 'blocks'!
getNewestBlock
    ^ #('Sprites' 'motion' ('set rotation style to %r' #- #rotationStyle:))! !
!CustomBlockSpecsDictionary class methodsFor: 'argMorphs'!
newestArg
    
^ Array with: $r
    with: (ChoiceArgMorph new getOptionsSelector: #rotationStyleChanger ;    choice: 'normal')! !

!ScriptableScratchMorph methodsFor: 'other ops'!
rotationStyleChanger
    ^ #('normal' 'leftRight' 'none' )! !

Here is how it works:
Part 1: The code:

!ScratchSpriteMorph methodsFor: 'accessing' stamp: 'jm 12/1/2006 11:30'!
rotationStyle: aSymbol
    "Set my rotation style to #normal, #leftRight, or #none. Styles mean:
        #normal    -- smooth 360 degree rotation
        #leftRight    -- flip about the vertical axis
        #none        -- do not rotate"

    rotationStyle _ aSymbol.
    self costumeChanged.
    self positionTalkBubble.
! !

part 2: the block spec:

!CustomBlockSpecsDictionary class methodsFor: 'blocks'!
getNewestBlock
    ^ #('Sprites' 'motion' ('set rotation style to %r' #- #rotationStyle:))! !

part 3: the custom arg specification

!CustomBlockSpecsDictionary class methodsFor: 'argMorphs'!
newestArg
    
^ Array with: $r
    with: (ChoiceArgMorph new getOptionsSelector: #rotationStyleChanger ;    choice: 'normal')! !

part 4: the custom arg options selector:

!ScriptableScratchMorph methodsFor: 'other ops'!
rotationStyleChanger
    ^ #('normal' 'leftRight' 'none' )! !

Greenatic wrote:

That looks great!      Please let us know when you have a beta to be released.   

Released. Try it! http://scratch.mit.edu/projects/dreamod/2482921

Greenatic wrote:

dreamod wrote:

Greenatic wrote:

That looks great!      Please let us know when you have a beta to be released.   

Released. Try it! http://scratch.mit.edu/projects/dreamod/2482921

Clicking the Blocks Menu results in the error: "NonBoolean receiver--proceed for truth".  Proceeding a few times fixes it though.

Saving a block results in the error: "Message not understood: saveNewBlock:", and I get a block called "re-initializing custom block specs".

Well, you got further than me! I downloaded it and that was about it. 

Greenatic wrote:

dreamod wrote:

Greenatic wrote:

That looks great!      Please let us know when you have a beta to be released.   

Released. Try it! http://scratch.mit.edu/projects/dreamod/2482921

Clicking the Blocks Menu results in the error: "NonBoolean receiver--proceed for truth".  Proceeding a few times fixes it though.  This error is also triggered by selecting "Create block".


Saving a block results in the error: "Message not understood: saveNewBlock:", and I get a block called "re-initializing custom block specs".  The block I made is not saved.

Well, actually, the motion "re-initalizing custom block specs" always starts off there.  The only way to get rid of it is to re-initialize the library.

Ok.
1st error: The Variable AdvancedMode is nil, which is not a boolean.Typing

Smalltalk at: #AdvancedMode put: false.

should solve the first problem. Since there are two modes, I use a boolean variable, true is advanced and false is not so advanced. The Create A Block Dialog is also very different in advanced mode so I use the AdvancedMode variable while initializing the dialog.

2nd Error: I forgot to file-out the method #saveNewBlock: when I made the patch. It was placed under 'accessing' instead of 'blocks'.

3rd Error: The 're-initializing custom block specs' block is supposed to be there when your re-initializing the custom block specs (basically, removing everything and starting fresh).

Thank you for reporting the bugs. I have updated the project, with bugs fixed in the patch.

Greenatic wrote:

dreamod wrote:

Greenatic wrote:

Clicking the Blocks Menu results in the error: "NonBoolean receiver--proceed for truth".  Proceeding a few times fixes it though.  This error is also triggered by selecting "Create block".


Saving a block results in the error: "Message not understood: saveNewBlock:", and I get a block called "re-initializing custom block specs".  The block I made is not saved.

Well, actually, the motion "re-initalizing custom block specs" always starts off there.  The only way to get rid of it is to re-initialize the library.

Ok.
1st error: The Variable AdvancedMode is nil, which is not a boolean.Typing

Code:

Smalltalk at: #AdvancedMode put: false.

should solve the first problem. Since there are two modes, I use a boolean variable, true is advanced and false is not so advanced. The Create A Block Dialog is also very different in advanced mode so I use the AdvancedMode variable while initializing the dialog.

2nd Error: I forgot to file-out the method #saveNewBlock: when I made the patch. It was placed under 'accessing' instead of 'blocks'.

3rd Error: The 're-initializing custom block specs' block is supposed to be there when your re-initializing the custom block specs (basically, removing everything and starting fresh).

Thank you for reporting the bugs. I have updated the project, with bugs fixed in the patch.

1st Error: Fixed.
2nd Error:  I re-filed in the patch in the first post, but the problem wasn't fixed.
3rd Error: But there's two of them...?

Another question:  What filetype are block files?
And another     Can args be created in a block file are do they need to be in seperate files?

New error:  selecting "Support" from the Blocks menu results in "Message not understood: parse:".

1: 
2: The patch in the first post is SERIOUSLY outdated. Do you mean the one on the project?
3: Does that really matter?

Q And A

Q: "What filetype are block files?"
A: Block file types are plain text files that get filed-in to the system, when imported.

Q: "Can args be created in a block file or do they need to be in seperate files?"
A: Short Answer: No.
    Long Answer: Yes, When you create a block and an arg, you can open them with TextEdit (or Microsoft Word) and add the arg contents into the block file and save it.

Hmmm... The last error, is another thing I forgot to file-out. I used panther's FormatCodeParser, which allows different fonts and links. I forgot to file-out that.