[squeakland] Etoys scripting broken on Mac OS X Leopard: drag and drop into script holder script?

[Merik Voswinkel]

Hi Yoshiki,

On May 9, 2008, at 8:06 AM, Yoshiki Ohshima wrote:

>  Merik,
>
>> Since a few months I can not create tile scripts in Etoys anymore. I
>> can drag a tile from a viewer and drop it anywhere and a new script
>> holder appears around my dropped tile. But when I drag a second tile
>> (script phrase) from the viewer and hover over the script holder no
>> insertion point appears.
>
>  The second tile wasn't a variable reference, yes?  If it was, the
> scriptor wouldn't take it as it is not a command or assignment.

I am ashamed to admit it was!
Skip the rest of my answers if you do not care about how this  
confusion came about.


I now see there are at least three types, the commands like "turtle1's  
forward by",
a assignment "turtle1's x" with a purple left-arrow in it and an  
viewer/assignment like "turtle1's angleTo".

The second tile I was attempting to drop was "turtle1's angleTo" and  
that still does not work,
but I now see that it is intended behavior, not broken.

>  If your first tile and the second tiles are the "forward by" command
> tiles, what happens?

Than it accepts the second tile by showing the insertion point during  
drag/hover and it accepts a drop.
It also accepts the assignment "turtle1's x" with a purple left-arrow  
in it IF we pick it up with the arrow.
I still can not drag and drop "turtle1's angleTo" but I now think the  
kids will figure that out why.

So nothing broken, the problem was confusion on my part.
Actually the children I am helping who run into the 'problem', but I  
should have done my homework better before asking.

>  And, when you say a new script holder, that is the one with yellow
> exclamation mark button and script name and, etc. where you edit the
> script, yes?  Let us call it a script editor.  (In the later version
> of OLPC Etoys, we introduced a different thing called
> ScriptingTileHolder that wraps a naked tile.)

Yes, we are both talking about a script editor.

>> When I drop the tile on top of the script holder it does not get
>> embedded but becomes a seperate tile on the background/desktop.
>> No attempt to put it into the script holder works,
>
>  Unless you get the green drop zone, the script editor won't accept
> the dropped tile.

Yes, a dark green drop zone on the light green script editor background.
>
>
>> When I use the halo I can see that the script holder does excepts
>> drops.The second tile could also gets no new script holder around it,
>> no mater where I drop it,
>
>  How did you check if the "script holder expects (?) drops"?

I looked in the halo menu 'accepts drops'.

>> I tried it on the Squeakland (browser plugin) (version 3.0), I
>> downloaded the XO image and also tried it on a regular squeak 3.9
>> image but nowhere do I get it to work.
>
>  What do you mean by "download the XO image and also tried
> it on a regular squeak 3.9 image"?  You tried it on the XO image and
> Squeak 3.9 image?

Yes, on several images.
>
>
>> I use Mac OS X Leopard on a fast G5 Quad so maybe therein lies the
>> problem?
>>
>> It took me a few months to post this because I thought it had
>> something to do with my Universel Access settings on Leopard that was
>> interfering with drag and drop elsewhere in Mac OS X like the finder.
>> But no, I have reinstalled a clean Leopard and the problem still  
>> exists.
>
>  Etoys' UI is completely independent from the platform.

Ok.
We did have those nasty problems with Universal Access interfering  
with other
modifiers of mouse behaviors however. This was hard to track down and  
took
a lot of time, but not related to Etoys of course.
In that process I tested drag and drop of tiles in Etoys so many times  
(without
wanting to actually program anything in Etoys, the children where  
doing that)
that I was not thinking about the possibility of different types of  
tiles with different drop behaviors.
So when I returned to the problems months later I was careless and did  
not think
at all about different behaviors, just tested the drops and seeing  
that there was
no drop zone and no embedding, totally ignoring the logic of the  
interface.
And then I wrote tis post, thinking it still that same Universal  
Access problem.

>> This effectively makes Etoys (and Kedama) unusable so I think it
>> should be resolved.
>> Where to look for a solution?
>> Has anybody heard about this problem before?
>
>  From your description, it is very hard to see what was actually
> going on, but I would think that there is some simpler
> misunderstanding like trying to drop a value reference onto the place
> where the script editor expects a command or an assignment.

Yes, you are right. I hope I clarified some of it.

Thank you very much on your time.

Merik