DockingBarMorph appears to hang onto windows.

That field is used to get focus back to where you were.

  - editing in a code-pane somewhere..
  - press Control+1 to invoke the Squeak menu.
  - press ESC because I changed my mind.
  - focus is back to where I was without ever having touched the mouse.

There are several places where the system latches on to objects
unexpectedly like this.

Normal usage of the system can't know whether its referencing a
"large" object.  If you are feeling annoyed by presence of large
objects, then I think that should be addressed by a separate use-case
-- an explicit cleanUp operation.

On Sun, May 20, 2012 at 12:06 PM, Eliot Miranda <[hidden email]> wrote:
> Hi All,
>
>    through a combination of the windows menu and oldKeyboardFocus and
> oldMouseFocus the DockingBarMorph holds onto closed windows.  Repeat by e.g.
>
> - inspect a new instance of some class that has no instances (ZeroDivide
> works for me).
>
> - Click on the Windows menu to populate it (it should include the ZeroDivide
> inspector).
>
> - Close the inspector, run the GC (e.g. ask for space left).
>
> - Then check the class's instance count (ZeroDivide instanceCount).  Should
> be non-zero.
>
> - Inspect the instance (ZeroDivide allInstances inspect) and do chase
> pointers and you'll get a reference back through the DockingBarMorph:
>
> globals: SystemDictionary
> #World -> PasteUpMorph
> submorphs: Array
> 2: DockingBarMorph
> oldKeyboardFocus: TextMorphForEditView
> editView: PluggableTextMorphPlus
> model: Inspector
> object: ZeroDivide
>
> - To clear, open the WIndows menu again (which now doesn't show the closed
> inspector) and run GC.  Now check instanceCount and it is back to zero.
>
> This is annoying because it can hold onto large objects.  I guess when
> morphs are deleted from the world they ought to clear themselves from the
> DockingBarMorph.  But I'm a bit nervous about making such a change, and
> hence thought I'd run it by the list first.
> --
> best,
> Eliot
>
>
>
>