#6955 LOW Never A: "tile" morph embedded in a "ScriptingTileMorph"

[Zarro Boogs per Child]

#6955: "tile" morph embedded in a "ScriptingTileMorph"
-----------------------------+----------------------------------------------
  Reporter:  dmoco           |       Owner:  etoys         
      Type:  defect          |      Status:  new           
  Priority:  low             |   Milestone:  Never Assigned
 Component:  etoys-activity  |     Version:                
Resolution:                  |    Keywords:                
  Verified:  0               |    Blocking:                
 Blockedby:                  |  
-----------------------------+----------------------------------------------

Comment(by ScottWallace):

 Replying to [comment:4 dmoco]:
 > Replying to [comment:2 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."

-- 
Ticket URL: <http://dev.laptop.org/ticket/6955#comment:6>
One Laptop Per Child <http://laptop.org/>
OLPC bug tracking system