#7315 NORM Never A: Using "scale factor" on a PasteUpMorph interferes with Viewer updating.

[Zarro Boogs per Child]

#7315: Using "scale factor" on a PasteUpMorph interferes with Viewer updating.
-----------------------------------------------------------------------+----
 Reporter:  dmoco                                                      |       Owner:                
     Type:  defect                                                     |      Status:  new           
 Priority:  normal                                                     |   Milestone:  Never Assigned
Component:  not assigned                                               |     Version:  Update.1      
 Keywords:  scale factor transform transformmorph holder pasteupmorph  |    Verified:  0             
 Blocking:                                                             |   Blockedby:                
-----------------------------------------------------------------------+----
 Any scale factor other than 1.0 triggers the wrapping of a morph in a
 TransformationMorph (TM for short). Particularly in a PasteUpMorph  used
 as a holder this wrapping causes the collection category variables to be
 out-of-step with the actual morph (not updated at all in some cases) and
 scripts using tiles such as "value at cursor" fail.

 Another effect is that a scaled holder itself (maybe the TM?) rather than
 the holders contents gets included in target holders. Yet another effect
 is content getting added to the TM instead. Eventually the failure to
 display a morph, it's owner, or potentially the morphic world.

 I note the various issues with TM's going back many years and the
 resolution always appears to be to treat the symptom rather than the
 problem or that Tweak is the solution (just stating the fact, no offence
 intended). Is there a reason why transform parameters cannot (optionally)
 be attributes of a morph instead of using a TM wrapper?

 The obvious quick fix for etoy scripts and collection operations is to set
 the scaling factor to 1.0 before performing the operation. However this
 will probably not avoid problems arising from including a scaled holder in
 another holder for example.

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