[etoys-dev] Etoys: Etoys-kfr.95.mcz
Bert Freudenberg
bert at freudenbergs.de
Wed Oct 26 05:14:46 EDT 2011
On 26.10.2011, at 11:03, karl ramberg wrote:
>> 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 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 -
More information about the etoys-dev
mailing list