Opened 6 years ago

Closed 6 years ago

#6955 closed enhancement (wontfix)

"tile" morph embedded in a "ScriptingTileMorph"

Reported by: dmoco Owned by: etoys
Priority: low Milestone: Future Release
Component: etoys-activity Version:
Keywords: Cc:
Blocked By: Blocking:
Deployments affected: Action Needed:
Verified: no

Description

Get a tile for an object and drop it on a Project link (make sure to see msg "Got it!"). Open other project and try to find menu option "Hand me this object" for the tile. Problem is tiles are now embedded in a "ScriptingTileMorph" so inner object, the actual "tile", has to be selected first.

Change History (10)

comment:1 follow-up: Changed 6 years ago by dmoco

(WinXP, assuming that fact makes a difference)

comment:2 follow-up: Changed 6 years ago by ScottWallace

  • Priority changed from normal to low

(1) Simply getting a tile for an object from its orange halo handle and dropping it on the desktop suffices to reproduce this phenomenon -- no need for the circumlocution of dropping it onto a project link, entering the other project, etc., which is only a red herring here.

(2) The phenomenon is not a bug. For a variety of reasons, long ago it was determined to be appropriate to "wrap" any "naked tiles" sitting on the desktop in a neutral "holder". This indeed does mean that if you want to get a halo on some inner structure within the tile holder, multiple halo-clicks may be required.

comment:3 in reply to: ↑ 1 ; follow-up: Changed 6 years ago by ohshima

Replying to dmoco:

(WinXP, assuming that fact makes a difference)

In general, these the interaction inside of Squeak is platform independent.

comment:4 in reply to: ↑ 2 ; follow-up: Changed 6 years ago by dmoco

Replying to ScottWallace:

(1) Simply getting a tile for an object from its orange halo handle and dropping it on the desktop suffices to reproduce this phenomenon -- no need for the circumlocution of dropping it onto a project link, entering the other project, etc., which is only a red herring here.

Yes, sorry for not checking this. As far as I remember I have only ever dropped a tile onto a script or a project view. The latter case is common for me because I typically experiment in one project and then move morphs to a new project if I want to preserved them.

(2) The phenomenon is not a bug. For a variety of reasons, long ago it was determined to be appropriate to "wrap" any "naked tiles" sitting on the desktop in a neutral "holder". This indeed does mean that if you want to get a halo on some inner structure within the tile holder, multiple halo-clicks may be required.

Which differs from non-olpc versions of Squeak (although having just performed a test on 3.10 I realise EToys has other problems on that release). Can you tell me the rationale for the wrapping? An explanation may help me avoid reporting other non-bugs. Also is there is another more obvious way for transferring morphs between projects? I ask because if I struggled to figure out what was going on then surely others will.

comment:5 in reply to: ↑ 3 Changed 6 years ago by dmoco

Replying to ohshima:

Replying to dmoco:

(WinXP, assuming that fact makes a difference)

In general, these the interaction inside of Squeak is platform independent.

Noted. I will be more discriminating in future (no XO here to check against).

comment:6 in reply to: ↑ 4 ; follow-up: Changed 6 years ago by ScottWallace

Replying to dmoco:

Replying to ScottWallace:

(2) The phenomenon is not a bug. For a variety of reasons, long ago it was determined to be appropriate to "wrap" any "naked tiles" sitting on the desktop in a neutral "holder". This indeed does mean that if you want to get a halo on some inner structure within the tile holder, multiple halo-clicks may be required.

Which differs from non-olpc versions of Squeak (although having just performed a test on 3.10 I realise EToys has other problems on that release). Can you tell me the rationale for the wrapping? An explanation may help me avoid reporting other non-bugs.

The point of the wrapping is simply defensive: it's done to disable a variety of UI operations (both d&d and direct-manipulation) which are ill-defined, and/or can lead to actual errors, when applied to "naked" tiles that are not associated with a containing Scriptor. Originally we tried to deal with those issues on a case-by-case basis, providing bits of bulletproofing here and there on an ad-hoc way, but ultimately decided to settle on the general principle that direct-manipulation within "naked tiles" would simply not be allowed. This does disable some potentially useful sub-assemblies that one might like to make outside of a Scriptor, but has the benefit of providing a single, simple (if draconian) rule, and of avoiding quite a range of potential bugs and glitches.

Also is there is another more obvious way for transferring morphs between projects? I ask because if I struggled to figure out what was going on then surely others will.

Here are two alternatives:

(a) Put an object in a "shared flap" (you might need to create such a flap for this purpose if your image doesn't already have one)

(b) Use "copy to paste buffer" (found in the copy & print submenu of an object's halo menu), then, in the other project, use the "new morph..." submenu of the project's "world" menu, and choose "from paste buffer."

comment:7 in reply to: ↑ 6 ; follow-up: Changed 6 years ago by karl

Replying to ScottWallace:

... This does disable some potentially useful sub-assemblies that one might like to make outside of a Scriptor, but has the benefit of providing a single, simple (if draconian) rule, and of avoiding quite a range of potential bugs and glitches.

My main issue with ScriptingTileHolder is with test tiles which I often pull out and put one of the answer tiles back into the script. I guess it can become a habit to pull the answer tile out of the test before removing the test.

comment:8 in reply to: ↑ 7 Changed 6 years ago by ScottWallace

Replying to karl:

Replying to ScottWallace:

... This does disable some potentially useful sub-assemblies that one might like to make outside of a Scriptor, but has the benefit of providing a single, simple (if draconian) rule, and of avoiding quite a range of potential bugs and glitches.

My main issue with ScriptingTileHolder is with test tiles which I often pull out and put one of the answer tiles back into the script. I guess it can become a habit to pull the answer tile out of the test before removing the test.

Yep, that is certainly an annoyance.

comment:9 Changed 6 years ago by ScottWallace

  • Milestone changed from Never Assigned to Future Release
  • Type changed from defect to enhancement

comment:10 Changed 6 years ago by ScottWallace

  • Resolution set to wontfix
  • Status changed from new to closed
Note: See TracTickets for help on using tickets.