There seems to be a few related problems with the JToolbar object, both when
it removes itself from a window (when the user drags it out onto its own) and
when it resintalls itself back into the original window.

The problem is easy to reproduce. I've reproduced it on Kestrel under the
latest build on both WindowsNT and Solaris.

Here are the steps to reproduce it, interspersed with
descriptions of the problems I saw. I saw 3 different symptoms that may
in fact be 3 different bugs, but for now I'll submit them together in this
one bug pending further evaluation.

To reproduce:
- go to SwingSet2 demo directory

- run java -jar SwingSet2.jar

- Grab the toolbar and move it somewhere else on the desktop

BUG #1: The demo frames do not rearrange themselves to fill the
hole left behind by the nonexistent toolbar

- Select a different demo button in the toolbar (now the frames
in the demo window rearrange themselves appropriately to fill the
gap left by the toolbar).

- Select the first demo button again (internal frames demo)

- Close the toolbar

BUG #2: The toolbar positions itself at the origin of the window
itself, overlapping (or underlapping) the window frame, the menus,
and the demo canvas.

- Grab one of the frames in the demo canvas and move it around.

- Grab one of the inactive demo frames and move it around. Now
the tool bar repositions itself appropriately and the frames move
around to make room for it.

BUG #3: Although the demo canvas reshaped itself correctly,
the frame that you grabbed and are moving around is copying an
incorrect area on the screen to paint itself in its new positions.
Screen garbage is apparent all over the place.