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

[Derek O'Connell]

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