Issue with adding filters I can't seem to get the tile to load. Some trickery is going on here. With change set loaded the grapics tiles category i empty. Change getHue to getGraphic and a item is added to the graphics category in the viewer.
Load the following change set.
SketchMorph>>additionsToViewerCategories ^ #( (graphics ( (slot jhrj 'Change color hue with given amount' Number readOnly Player c notUsed notUsed )
Are there some behind the back filtering going on here ?
Karl
On Wed, Oct 26, 2011 at 11:14 AM, Bert Freudenberg bert@freudenbergs.de wrote:
On 26.10.2011, at 11:03, karl ramberg wrote:
On Tue, Oct 25, 2011 at 1:03 PM, Derek O'Connell doc@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 -
etoys-dev mailing list etoys-dev@squeakland.org http://lists.squeakland.org/mailman/listinfo/etoys-dev