Hi Karl,

the attached may be of some help. I have just dug them up from well over a year ago so I still need to refresh my memory about what's what. I'm sure I posted them at the time but anyway here they are.

-D

On 24/10/11 22:00, karl ramberg wrote:

Yes, these could be in SketchMorph instead. I also have to work out the range on the input of filter settings. But this quick hack gave much improvement. Just 5 methods to add all that functionality :-) Player 'restore base graphic' works great as an undo.

Karl

On Mon, Oct 24, 2011 at 9:31 PM, Bert Freudenbergbert@freudenbergs.de wrote:

...

IMHO these should be properties of a SketchMorph. When that property changes, its "rotatedForm" would be recomputed from its "originalForm", taking these properties into account (unless they have their default value). Sort of like independent filters - people rightly should expect this to work similar as in Scratch.

Btw, with all these new features I'm getting excited about the 2011 release :) We should name it 4.2, at least.

• Bert -

On 24.10.2011, at 17:59, commits@source.squeak.org wrote:

...

Karl Ramberg uploaded a new version of Etoys to project Etoys: http://source.squeak.org/etoys/Etoys-kfr.95.mcz

==================== Summary ====================

Name: Etoys-kfr.95 Author: kfr Time: 24 October 2011, 7:59:23 pm UUID: 238320d7-b378-a746-892f-c4a910ffa21d Ancestors: Etoys-bf.94

Add blur: brightness: satruation: and hue: to graphics category. Now possible to play a little with picture colors etc.

=============== Diff against Etoys-bf.94 ===============

Item was added:

• ----- Method: Player>>blur: (in category '*Etoys-Scratch') -----
• blur: aWidth

• | f fOut |
  

• f := self getGraphic asFormOfDepth: 32.
  

• fOut := f bits copy.
  

• ScratchPlugin
  

•         primBlur: f bits
  

•         into: fOut
  

•         width: f width + aWidth.
  

• f bits: fOut.
  

• self
  

•         setGraphic: (f asFormOfDepth: 16)!
  
  

Item was added:

• ----- Method: Player>>brightness: (in category '*Etoys-Scratch') -----
• brightness: aNumber

• | f fOut |
  

• f := self getGraphic asFormOfDepth: 32.
  

• fOut := f deepCopy.
  

• ScratchPlugin
  

•         primShiftBrightness: f bits
  

•         into: fOut bits
  

•         by: aNumber.
  

• self
  

•         setGraphic: (fOut asFormOfDepth: 16)!
  
  

Item was added:

• ----- Method: Player>>hue: (in category '*Etoys-Scratch') -----
• hue: aDegree

• | f fOut degree |
  

• degree := aDegree.
  

• degree>  180
  

•         ifTrue: [degree := -360 + degree].
  

• f := self getGraphic asFormOfDepth: 32.
  

• fOut := f deepCopy.
  

• ScratchPlugin
  

•         primShiftHue: f bits
  

•         into: fOut bits
  

•         byDegrees: degree.
  

• self
  

•         setGraphic: (fOut asFormOfDepth: 16)!
  
  

Item was added:

• ----- Method: Player>>saturation: (in category '*Etoys-Scratch') -----
• saturation: aNumber

• | f fOut |
  

• f := self getGraphic asFormOfDepth: 32.
  

• fOut := f deepCopy.
  

• ScratchPlugin
  

•         primShiftSaturation: f bits
  

•         into: fOut bits
  

•         by: aNumber.
  

• self
  

•         setGraphic: (fOut asFormOfDepth: 16)!
  
  

Item was changed: ----- Method: SketchMorph class>>additionsToViewerCategories (in category '*eToys-scripting') ----- additionsToViewerCategories

• ^ #(#(#graphics #(#(#slot #graphic 'The picture currently being worn' #Graphic #readWrite #Player #getGraphic #Player #setGraphic:) #(#command #wearCostumeOf: 'wear the costume of...' #Player) #(#slot #baseGraphic 'The picture originally painted for this object, but can subsequently be changed via menu or script' #Graphic #readWrite #Player #getBaseGraphic #Player #setBaseGraphic:) #(#command #restoreBaseGraphic 'Make my picture be the one I remember in my baseGraphic') #(#slot #rotationStyle 'How the picture should change when the heading is modified' #RotationStyle #readWrite #Player #getRotationStyle #Player #setRotationStyle:) #(#command #flipLeftRight 'Flip the picture left to right' #Player) #(#command #flipUpDown 'Flip the picture upside down' #Player) #(#command #blur: 'blur the image...' #Number) #(#command #hue: 'change color hue degree...' #Number) #(#command #brightness: 'change color brightness...' #Number) #(#command #saturation: 'change color saturation...'
  

#Number))) )!

• "Answer a list of (<categoryName>  <list of category specs>) pairs that characterize the phrases this kind of morph wishes to add to various Viewer categories."
  

• ^ #((graphics (
  

• (slot graphic 'The picture currently being worn' Graphic readWrite Player getGraphic Player setGraphic:)
• (command wearCostumeOf: 'wear the costume of...' Player)
• (slot baseGraphic 'The picture originally painted for this object, but can subsequently be changed via menu or script' Graphic readWrite Player getBaseGraphic Player setBaseGraphic:)
• (command restoreBaseGraphic 'Make my picture be the one I remember in my baseGraphic')
• (slot rotationStyle 'How the picture should change when the heading is modified' RotationStyle readWrite Player getRotationStyle Player setRotationStyle:)
• (command flipLeftRight 'Flip the picture left to right' Player)
• (command flipUpDown 'Flip the picture upside down' Player)
• )))
• !

---

etoys-dev mailing list etoys-dev@squeakland.org http://lists.squeakland.org/mailman/listinfo/etoys-dev

---

etoys-dev mailing list etoys-dev@squeakland.org http://lists.squeakland.org/mailman/listinfo/etoys-dev

---

etoys-dev mailing list etoys-dev@squeakland.org http://lists.squeakland.org/mailman/listinfo/etoys-dev

On 24.10.2011, at 23:00, karl ramberg wrote:

Yes, these could be in SketchMorph instead.

That's not the point. I am concerned with the behavior, not where it's implemented (although doing it in the morph would be the Right Thing).

When we introduce new behavior we make a promise that if users use that behavior, it will continue to work. Older projects should work in newer Etoys versions. So we need to get the basic behavior of a new tile right from the beginning. (if we wanted to allow experiments with your code we could hide the new tiles from normal users - e.g., there already are tile categories you only see by enabling some preference)

The behavior you introduce with these tiles is inferior to the Scratch model. It's procedural. It applies e.g. a hue shift but there is no way to read back the current hue shift. If you want a blurred, hue shifted sketch you would have to have a script that does "restore base graphic", "shift hue", "apply blur". If you want to change the blur value interactively, this script would have to be ticking all the time, which is hugely inefficient.

With the properties I was proposing, there simply would be some new slots in the viewer for hueShift, blurAmount, etc. Changing the blur amount in the viewer would immediately update the Sketch. No script needed. Setting it back to 0 would reveal the original unblurred image (and performance would be back to normal and the property would be removed). This would be like playing with the heading - as soon as you change the number in the viewer, the object on screen changes.

This is a bit like rolling Derek's ScratchEffectsMorph directly into SketchMorph. But it would be a lot simpler, there would be no new instance variables, etc.

*If* we were going to add a "special effects morph" then it should be general. You could drop any morph into it (be it a sketch or rectangle or camera) and it would apply some effects. Similarly to ScreeningMorph.

Or possibly it should even work invisibly, just like TransformationMorph. We would have the hue shift, blur, etc. slots on every object, and as soon as they are non-zero, a hidden FxRenderer morph would get inserted in the owner chain. From a user's point of view, this would just extend the functionality I am proposing for Sketches to every object, so this could be added in a later update since the functionality would be similar. Sketches would still be more efficient because they would cache the effects.

Basically what I'm saying is that it's great you want to expose the Scratch features for Etoys users, but we should discuss how to do that. I have been thinking about this for a while (ever since we were talking about including the plugin) and the above is what I concluded.

- Bert -

I also have to work out the range on the input of filter settings. But this quick hack gave much improvement. Just 5 methods to add all that functionality :-) Player 'restore base graphic' works great as an undo.

Karl

On Mon, Oct 24, 2011 at 9:31 PM, Bert Freudenberg bert@freudenbergs.de wrote:

...

IMHO these should be properties of a SketchMorph. When that property changes, its "rotatedForm" would be recomputed from its "originalForm", taking these properties into account (unless they have their default value). Sort of like independent filters - people rightly should expect this to work similar as in Scratch.

Btw, with all these new features I'm getting excited about the 2011 release :) We should name it 4.2, at least.

• Bert -

Yes, I should have published to the inbox instead of to the main repository. I'll fix that. The FilterPack class from Scratch can be a good startingpoint for what you describe. I'll take a look at it.

Karl

On Tue, Oct 25, 2011 at 1:03 PM, Derek O'Connell doc@doconnel.f9.co.uk wrote:

On 25/10/11 11:26, Bert Freudenberg wrote:

...

On 24.10.2011, at 23:00, karl ramberg wrote:

...

Yes, these could be in SketchMorph instead.

That's not the point. I am concerned with the behavior, not where  it's implemented (although doing it in the morph would be the Right  Thing).

When we introduce new behavior we make a promise that if users use  that behavior, it will continue to work. Older projects should work  in newer Etoys versions. So we need to get the basic behavior of a  new tile right from the beginning. (if we wanted to allow experiments  with your code we could hide the new tiles from normal users - e.g.,  there already are tile categories you only see by enabling some  preference)

The behavior you introduce with these tiles is inferior to the  Scratch model. It's procedural. It applies e.g. a hue shift but there  is no way to read back the current hue shift. If you want a blurred,  hue shifted sketch you would have to have a script that does "restore  base graphic", "shift hue", "apply blur". If you want to change the  blur value interactively, this script would have to be ticking all  the time, which is hugely inefficient.

With the properties I was proposing, there simply would be some new  slots in the viewer for hueShift, blurAmount, etc. Changing the blur  amount in the viewer would immediately update the Sketch. No script  needed. Setting it back to 0 would reveal the original unblurred  image (and performance would be back to normal and the property would  be removed). This would be like playing with the heading - as soon as  you change the number in the viewer, the object on screen changes.

This is a bit like rolling Derek's ScratchEffectsMorph directly into  SketchMorph. But it would be a lot simpler, there would be no new  instance variables, etc.

*If* we were going to add a "special effects morph" then it should be  general. You could drop any morph into it (be it a sketch or  rectangle or camera) and it would apply some effects. Similarly to  ScreeningMorph.

Or possibly it should even work invisibly, just like  TransformationMorph. We would have the hue shift, blur, etc. slots on  every object, and as soon as they are non-zero, a hidden FxRenderer  morph would get inserted in the owner chain. From a user's point of  view, this would just extend the functionality I am proposing for  Sketches to every object, so this could be added in a later update  since the functionality would be similar. Sketches would still be  more efficient because they would cache the effects.

Basically what I'm saying is that it's great you want to expose the  Scratch features for Etoys users, but we should discuss how to do  that. I have been thinking about this for a while (ever since we were  talking about including the plugin) and the above is what I  concluded.

My take on all this last year was biased toward touch-screen based devices hence the idea of a designated fx-holder to drag&drop fx morphs to, easily change order in which applied and bring up individual viewers for tweaking. So, no scripting required for quick/simple experimentation but still scriptable if desired. I had also planned to optionally have each fx morph change appearance to show individual/chained effect on the source image.

-D

...

- Bert -

...

I also have to work out the range on the input of filter settings. But this quick hack gave much improvement. Just 5 methods to add all that functionality :-) Player 'restore base graphic' works great as an undo.

Karl

On Mon, Oct 24, 2011 at 9:31 PM, Bert Freudenberg bert@freudenbergs.de wrote:

...

IMHO these should be properties of a SketchMorph. When that property changes, its "rotatedForm" would be recomputed from its "originalForm", taking these properties into account (unless they have their default value). Sort of like independent filters - people rightly should expect this to work similar as in Scratch.

Btw, with all these new features I'm getting excited about the 2011 release :) We should name it 4.2, at least.

• Bert -

_______________________________________________ etoys-dev mailing  list etoys-dev@squeakland.org  http://lists.squeakland.org/mailman/listinfo/etoys-dev

---

etoys-dev mailing list etoys-dev@squeakland.org http://lists.squeakland.org/mailman/listinfo/etoys-dev

On 26.10.2011, at 11:03, karl ramberg wrote:

...

On Tue, Oct 25, 2011 at 1:03 PM, Derek O'Connell doc@doconnel.f9.co.uk wrote:

...

On 25/10/11 11:26, Bert Freudenberg wrote:

...

On 24.10.2011, at 23:00, karl ramberg wrote:

...

Yes, these could be in SketchMorph instead.

That's not the point. I am concerned with the behavior, not where it's implemented (although doing it in the morph would be the Right Thing).

When we introduce new behavior we make a promise that if users use that behavior, it will continue to work. Older projects should work in newer Etoys versions. So we need to get the basic behavior of a new tile right from the beginning. (if we wanted to allow experiments with your code we could hide the new tiles from normal users - e.g., there already are tile categories you only see by enabling some preference)

The Etoys category code is hard to read :-( I'm not really sure how to extend and enable more categories using the preferences. I have tested a little but have not found a solution yet.

See filterViewerCategoryDictionary:.

...

...

...

The behavior you introduce with these tiles is inferior to the Scratch model. It's procedural. It applies e.g. a hue shift but there is no way to read back the current hue shift. If you want a blurred, hue shifted sketch you would have to have a script that does "restore base graphic", "shift hue", "apply blur". If you want to change the blur value interactively, this script would have to be ticking all the time, which is hugely inefficient.

With the properties I was proposing, there simply would be some new slots in the viewer for hueShift, blurAmount, etc. Changing the blur amount in the viewer would immediately update the Sketch. No script needed. Setting it back to 0 would reveal the original unblurred image (and performance would be back to normal and the property would be removed). This would be like playing with the heading - as soon as you change the number in the viewer, the object on screen changes.

This is a bit like rolling Derek's ScratchEffectsMorph directly into SketchMorph. But it would be a lot simpler, there would be no new instance variables, etc.

*If* we were going to add a "special effects morph" then it should be general. You could drop any morph into it (be it a sketch or rectangle or camera) and it would apply some effects. Similarly to ScreeningMorph.

In Scratch you have the sprite morph do the drawing so switching out the form is a little easier and cleaner. Player is not involved in drawing so it's a little trickier in Etoys. A ScreeningMorph could work.

But SketchMorph is very similar to a Scratch sprite. That's why I think the best solution is to just add those slots to SketchMorph. Player has nothing to do with that, it's purely for scripting.

- Bert -

On 27/10/11 00:30, karl ramberg wrote:

Issue with adding filters I can't seem to get the tile to load. Some trickery is going on here. With change set loaded the grapics tiles category i empty. Change getHue to getGraphic and a item is added to the graphics category in the viewer.

Load the following change set.

SketchMorph>>additionsToViewerCategories ^ #( (graphics ( (slot jhrj 'Change color hue with given amount' Number readOnly Player c notUsed notUsed )

Are there some behind the back filtering going on here ?

Karl

There is a method to search for conflicts and display results in a transcript, do-it...

ScriptingSystem searchForSlotProtocolConflicts

This showed a conflict for "getHue" so I changed your Player method to "getSketchHue", switched the view category to ensure it updated and then it displayed the tile.

-D

"hue" isn't correct anyway. It's not not setting the hue of the sketch. It is changing the hue of each pixel by the given amount. "hue shift" (or "hue change") would be much more appropriate. Perhaps there is a single English word for that? Maybe "tint"? Not being a native speaker I can't think of a good one. [btw, Scratch calls it "color effect" which is less specific]

- Bert -

On 27.10.2011, at 09:08, Derek O'Connell wrote:

On 27/10/11 08:05, Derek O'Connell wrote:

...

On 27/10/11 00:30, karl ramberg wrote:

...

Issue with adding filters I can't seem to get the tile to load. Some trickery is going on here. With change set loaded the grapics tiles category i empty. Change getHue to getGraphic and a item is added to the graphics category in the viewer.

Load the following change set.

SketchMorph>>additionsToViewerCategories ^ #( (graphics ( (slot jhrj 'Change color hue with given amount' Number readOnly Player c notUsed notUsed )

Are there some behind the back filtering going on here ?

Karl

There is a method to search for conflicts and display results in a transcript, do-it...

ScriptingSystem searchForSlotProtocolConflicts

This showed a conflict for "getHue" so I changed your Player method to "getSketchHue", switched the view category to ensure it updated and then it displayed the tile.

-D

and...

additionsToViewerCategories ^ #(#(#graphics #(#(#slot #hue 'hue' #Number #readOnly #Player #getSketchHue #Player #unused))) )

---

etoys-dev mailing list etoys-dev@squeakland.org http://lists.squeakland.org/mailman/listinfo/etoys-dev

On 27.10.2011, at 13:40, Walter Bender wrote:

On Thu, Oct 27, 2011 at 7:33 AM, Bert Freudenberg bert@freudenbergs.de wrote:

...

"hue" isn't correct anyway. It's not not setting the hue of the sketch. It is changing the hue of each pixel by the given amount. "hue shift" (or "hue change") would be much more appropriate. Perhaps there is a single English word for that? Maybe "tint"? Not being a native speaker I can't think of a good one. [btw, Scratch calls it "color effect" which is less specific]

On old analog TVs, it was called tint, with the implication that it was used to change the hue. I'd suggest combining a noun and a verb: 'shift hue'.

-walter

Ah, thanks. For a command name, "shift hue" would be good. But I was looking for a name for a property that could be dialed up and down. Default would be 0, meaning no change. That analog TV term sounds right to me.

Looking forward to see you tomorrow :)

- Bert -

On 27.10.2011, at 18:08, karl ramberg wrote:

On Thu, Oct 27, 2011 at 2:27 PM, Bert Freudenberg bert@freudenbergs.de wrote:

...

On 27.10.2011, at 13:40, Walter Bender wrote:

...

On Thu, Oct 27, 2011 at 7:33 AM, Bert Freudenberg bert@freudenbergs.de wrote:

...

"hue" isn't correct anyway. It's not not setting the hue of the sketch. It is changing the hue of each pixel by the given amount. "hue shift" (or "hue change") would be much more appropriate. Perhaps there is a single English word for that? Maybe "tint"? Not being a native speaker I can't think of a good one. [btw, Scratch calls it "color effect" which is less specific]

On old analog TVs, it was called tint, with the implication that it was used to change the hue. I'd suggest combining a noun and a verb: 'shift hue'.

-walter

Ah, thanks. For a command name, "shift hue" would be good. But I was looking for a name for a property that could be dialed up and down. Default would be 0, meaning no change. That analog TV term sounds right to me.

Looking forward to see you tomorrow :)

• Bert -

I had really not thought about the word hue and it's meaning. I'll use 'shift hue'. On the getter side should we reverse the wording to use 'hue shift' as we are getting the shift of hue ? Does that make sense ?

I think it does make sense. I just saw that even the primitive has the name "primitiveHueShift".

Regarding the words 'saturation' and 'brightness', are they ok to go or should we change them ?

The primitives are called primitiveBrightnessShift and primitiveSaturationShift, which seems verbose but correct.

- Bert -