[etoys-notify] [JIRA] Commented: (SQ-658) Paintings done on World do not delete properly

[Scott Wallace (JIRA)]

    [ http://tracker.squeakland.org/browse/SQ-658?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=39108#action_39108 ] 

Scott Wallace commented on SQ-658:
----------------------------------

This points to some problems that have accumulated about "background morphs" over time.  I offer the following recollections from (possibly inaccurate) memory FWIW:

The initial intent was that if a pasteup (world or playfield) had a "background", the morph holding the painting constituting the background was *not* in the pasteup's submorphs list but rather was accessed only through the pasteup's own "backgroundMorph" instance variable.  If you look in PasteUpMorph >> drawOn: you'll see that the background morph, if any, is separately rendered, in a part of the code distinct from the part that renders the submorphs, so that if in fact the backgroundMorph is also in the submorph tree, it will be rendered twice (!).

To repaint (by initial intent anyway,) you use the repaint-handle of halo of the world or playfield, not of the "background sketch" within, and the intended mechanism for *removing* a "background painting" from the world (or from a playfield) is through the "delete background painting" menu item in its "playfield options" menu.  If this is used, all the right things happen.

It was never intended that a "background sketch" ever itself bear the halo.  It has a special relationship to its corresponding pasteup, and the intention is that you deal with it through the pasteup's halo and menus. 

But now that the background sketch's halo is cheerfully offered (because the background sketch nowadays *is* for some reason in the submorph tree), the user is naturally tempted to use it to dismiss the background sketch using the X, leading to the bug reported in this ticket.  What's happening is that it gets removed from the submorph tree of the pasteup but *not* from its backgroundMorph slot.  Yet it's also been "moved" to the trash.  So much strangeness can ensue...

Three straightforward solutions suggest themselves, in increasing order of desirability IMHO:

(1) Reimplement StickySketchMorph >> dismissViaHalo so that it informs the corresponding pasteup of its imminent dismissal, so that the pasteup can remove the reference to it that it currently holds in its backgroundMorph slot.

(2) Better:  Implement StickySketchMorph>>wantsHaloFromClick, with "^ false" as its body.  This would keep the morph holding the background painting from ever itself getting the halo, so the user would never get into the error situation.

(3) Best of all:  enforce anew the policy that the background morph is *never* in the submorph tree. But maybe there was a good reason why it started appearing there, rather than simple, honest bit-rot, so one would have to be careful...

> Paintings done on World do not delete properly
> ----------------------------------------------
>
>                 Key: SQ-658
>                 URL: http://tracker.squeakland.org/browse/SQ-658
>             Project: squeakland
>          Issue Type: Bug
>          Components: etoys
>            Reporter: Stephen Thomas
>
> To recreate the problem:
> 1) Bring up the World's Halo
> 2) Click on "paint background" icon and draw a Sketch
> 3) Try to Delete the Sketch you just drew
> You should see the image of the Sketch remain on the screen, while there is a copy of it (or the sketch object itself) in the Trash. If you then click on the image left behind it willmove to the top left corner of the World.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://tracker.squeakland.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira