Etoys: Etoys-kfr.95.mcz

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
19 messages Options
Reply | Threaded
Open this post in threaded view
|

Etoys: Etoys-kfr.95.mcz

commits-2
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
[hidden email]
http://lists.squeakland.org/mailman/listinfo/etoys-dev
Reply | Threaded
Open this post in threaded view
|

Re: Etoys: Etoys-kfr.95.mcz

Bert Freudenberg
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, [hidden email] 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
> [hidden email]
> http://lists.squeakland.org/mailman/listinfo/etoys-dev



_______________________________________________
etoys-dev mailing list
[hidden email]
http://lists.squeakland.org/mailman/listinfo/etoys-dev
Reply | Threaded
Open this post in threaded view
|

Re: Etoys: Etoys-kfr.95.mcz

Karl Ramberg
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 Freudenberg <[hidden email]> 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, [hidden email] 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
>> [hidden email]
>> http://lists.squeakland.org/mailman/listinfo/etoys-dev
>
>
>
> _______________________________________________
> etoys-dev mailing list
> [hidden email]
> http://lists.squeakland.org/mailman/listinfo/etoys-dev
>
_______________________________________________
etoys-dev mailing list
[hidden email]
http://lists.squeakland.org/mailman/listinfo/etoys-dev
Reply | Threaded
Open this post in threaded view
|

Re: Etoys: Etoys-kfr.95.mcz

Derek O'Connell-3
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 Freudenberg<[hidden email]>  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, [hidden email] 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
>>> [hidden email]
>>> http://lists.squeakland.org/mailman/listinfo/etoys-dev
>>
>>
>> _______________________________________________
>> etoys-dev mailing list
>> [hidden email]
>> http://lists.squeakland.org/mailman/listinfo/etoys-dev
>>
> _______________________________________________
> etoys-dev mailing list
> [hidden email]
> http://lists.squeakland.org/mailman/listinfo/etoys-dev

_______________________________________________
etoys-dev mailing list
[hidden email]
http://lists.squeakland.org/mailman/listinfo/etoys-dev

VideoFx.st (47K) Download Attachment
ScratchEffects.st (15K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Etoys: Etoys-kfr.95.mcz

Derek O'Connell-3
On 24/10/11 22:48, Derek O'Connell wrote:
>  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

Agh, a quick test shows it doesn't work in they etoys I have here. Will
take a look tomorrow.

_______________________________________________
etoys-dev mailing list
[hidden email]
http://lists.squeakland.org/mailman/listinfo/etoys-dev
Reply | Threaded
Open this post in threaded view
|

Re: Etoys: Etoys-kfr.95.mcz

Bert Freudenberg
In reply to this post by Karl Ramberg
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 <[hidden email]> 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
[hidden email]
http://lists.squeakland.org/mailman/listinfo/etoys-dev
Reply | Threaded
Open this post in threaded view
|

Re: Etoys: Etoys-kfr.95.mcz

Derek O'Connell-3
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
> > <[hidden email]> 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 [hidden email]
>  http://lists.squeakland.org/mailman/listinfo/etoys-dev


_______________________________________________
etoys-dev mailing list
[hidden email]
http://lists.squeakland.org/mailman/listinfo/etoys-dev
Reply | Threaded
Open this post in threaded view
|

Re: Etoys: Etoys-kfr.95.mcz

Karl Ramberg
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 <[hidden email]> 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
>> > <[hidden email]> 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 [hidden email]
>>  http://lists.squeakland.org/mailman/listinfo/etoys-dev
>
>
> _______________________________________________
> etoys-dev mailing list
> [hidden email]
> http://lists.squeakland.org/mailman/listinfo/etoys-dev
>
_______________________________________________
etoys-dev mailing list
[hidden email]
http://lists.squeakland.org/mailman/listinfo/etoys-dev
Reply | Threaded
Open this post in threaded view
|

Re: Etoys: Etoys-kfr.95.mcz

Karl Ramberg
> On Tue, Oct 25, 2011 at 1:03 PM, Derek O'Connell <[hidden email]> 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.

>>>
>>>  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.

Karl
_______________________________________________
etoys-dev mailing list
[hidden email]
http://lists.squeakland.org/mailman/listinfo/etoys-dev
Reply | Threaded
Open this post in threaded view
|

Re: Etoys: Etoys-kfr.95.mcz

Bert Freudenberg

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

>> On Tue, Oct 25, 2011 at 1:03 PM, Derek O'Connell <[hidden email]> 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 -


_______________________________________________
etoys-dev mailing list
[hidden email]
http://lists.squeakland.org/mailman/listinfo/etoys-dev
Reply | Threaded
Open this post in threaded view
|

Re: Etoys: Etoys-kfr.95.mcz

Karl Ramberg
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




On Wed, Oct 26, 2011 at 11:14 AM, Bert Freudenberg <[hidden email]> wrote:

>
> On 26.10.2011, at 11:03, karl ramberg wrote:
>
>>> On Tue, Oct 25, 2011 at 1:03 PM, Derek O'Connell <[hidden email]> 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 -
>
>
> _______________________________________________
> etoys-dev mailing list
> [hidden email]
> http://lists.squeakland.org/mailman/listinfo/etoys-dev
>

_______________________________________________
etoys-dev mailing list
[hidden email]
http://lists.squeakland.org/mailman/listinfo/etoys-dev

Unnamed2.1.cs (2K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Etoys: Etoys-kfr.95.mcz

Derek O'Connell-3
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

_______________________________________________
etoys-dev mailing list
[hidden email]
http://lists.squeakland.org/mailman/listinfo/etoys-dev
Reply | Threaded
Open this post in threaded view
|

Re: Etoys: Etoys-kfr.95.mcz

Derek O'Connell-3
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
[hidden email]
http://lists.squeakland.org/mailman/listinfo/etoys-dev
Reply | Threaded
Open this post in threaded view
|

Re: Etoys: Etoys-kfr.95.mcz

Bert Freudenberg
"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
> [hidden email]
> http://lists.squeakland.org/mailman/listinfo/etoys-dev



_______________________________________________
etoys-dev mailing list
[hidden email]
http://lists.squeakland.org/mailman/listinfo/etoys-dev
Reply | Threaded
Open this post in threaded view
|

Re: Etoys: Etoys-kfr.95.mcz

Walter Bender
On Thu, Oct 27, 2011 at 7:33 AM, Bert Freudenberg <[hidden email]> 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

>
> - 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
>> [hidden email]
>> http://lists.squeakland.org/mailman/listinfo/etoys-dev
>
>
>
> _______________________________________________
> etoys-dev mailing list
> [hidden email]
> http://lists.squeakland.org/mailman/listinfo/etoys-dev
>



--
Walter Bender
Sugar Labs
http://www.sugarlabs.org
_______________________________________________
etoys-dev mailing list
[hidden email]
http://lists.squeakland.org/mailman/listinfo/etoys-dev
Reply | Threaded
Open this post in threaded view
|

Re: Etoys: Etoys-kfr.95.mcz

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

> On Thu, Oct 27, 2011 at 7:33 AM, Bert Freudenberg <[hidden email]> 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 -


_______________________________________________
etoys-dev mailing list
[hidden email]
http://lists.squeakland.org/mailman/listinfo/etoys-dev
Reply | Threaded
Open this post in threaded view
|

Re: Etoys: Etoys-kfr.95.mcz

Karl Ramberg
In reply to this post by Derek O'Connell-3
On Thu, Oct 27, 2011 at 9:05 AM, Derek O'Connell <[hidden email]> 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.

Thanks.
This is great.
I really got lost in the code here :-)

Karl
_______________________________________________
etoys-dev mailing list
[hidden email]
http://lists.squeakland.org/mailman/listinfo/etoys-dev
Reply | Threaded
Open this post in threaded view
|

Re: Etoys: Etoys-kfr.95.mcz

Karl Ramberg
In reply to this post by Bert Freudenberg
On Thu, Oct 27, 2011 at 2:27 PM, Bert Freudenberg <[hidden email]> wrote:

> On 27.10.2011, at 13:40, Walter Bender wrote:
>
>> On Thu, Oct 27, 2011 at 7:33 AM, Bert Freudenberg <[hidden email]> 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 ?

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

Karl
_______________________________________________
etoys-dev mailing list
[hidden email]
http://lists.squeakland.org/mailman/listinfo/etoys-dev
Reply | Threaded
Open this post in threaded view
|

Re: Etoys: Etoys-kfr.95.mcz

Bert Freudenberg

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

> On Thu, Oct 27, 2011 at 2:27 PM, Bert Freudenberg <[hidden email]> wrote:
>> On 27.10.2011, at 13:40, Walter Bender wrote:
>>
>>> On Thu, Oct 27, 2011 at 7:33 AM, Bert Freudenberg <[hidden email]> 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 -


_______________________________________________
etoys-dev mailing list
[hidden email]
http://lists.squeakland.org/mailman/listinfo/etoys-dev