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