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

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Merik Voswinkel

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.
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,

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,

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.

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.

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?

Merik



_______________________________________________
Squeakland mailing list
[hidden email]
http://squeakland.org/mailman/listinfo/squeakland
Reply | Threaded
Open this post in threaded view
|

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

Yoshiki Ohshima-2
  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.  If
your first tile and the second tiles are the "forward by" command
tiles, what happens?

  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.)

> 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.

> 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 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?

> 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.  

> 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.

  You don't have to try different images or such.  In whatever image,
please explain us what you exactly did.

-- Yoshiki

_______________________________________________
Squeakland mailing list
[hidden email]
http://squeakland.org/mailman/listinfo/squeakland
Reply | Threaded
Open this post in threaded view
|

Re: 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

_______________________________________________
Squeakland mailing list
[hidden email]
http://squeakland.org/mailman/listinfo/squeakland
Reply | Threaded
Open this post in threaded view
|

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

Yoshiki Ohshima-2
> Skip the rest of my answers if you do not care about how this  
> confusion came about.

  Well, now I can't skip...

> >  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.

  Not sure what you mean by Universal Access interfere (something like
lockable Shift key?)

  One could argue that a plain expression could be dropped onto a
script editor, and the user could expand it into a meaningful
statement afterwards.  But current system is not flexible enough to
allow this.

-- Yoshiki

_______________________________________________
Squeakland mailing list
[hidden email]
http://squeakland.org/mailman/listinfo/squeakland