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
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
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
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@lists.squeakfoundation.org
-
Merik Voswinkel -
Yoshiki Ohshima