[etoys-dev] Etoys: Etoys-kfr.95.mcz

[Bert Freudenberg]

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