[etoys-dev] Etoys: Etoys-kfr.95.mcz
doc at doconnel.f9.co.uk
Tue Oct 25 07:03:41 EDT 2011
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
> 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
> 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
> 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
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
> - 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
More information about the etoys-dev