3.  Window geometry management is a mess.
    Perhaps someone would care to suggest a better approach?
    Currently there are two basic approaches that can be taken with
    any plug window.
    If gridding is turned on, then the geometry of the toplevel window
    containing the plug will have gridding matching the underlying window.
    However, the plug will not initialy be sized to match the underlying window!
    The plug size must be tied to the toplevel frame size (using the packer),
    and the toplevel windows initial geometry must be made to match the
    plug's initial client geometry using an explicit "wm geometry" command.
    Note that furthermore, the frame containing the plug window must be such
    that if the plug requests a 0x0 geometry, then it will not be expanded
    unless a "wm geometry" command is issued to resize the toplevel window
    containing the plug.
    Alternatively, a window can have gridding turned off, in which case
    the initial requested size of the plug matches the client window exactly.
    The plug will force the client to track changes imposed in response to
    "wm geometry" commands, and the user can change the requested size
    of the plug directly using the "plugPath geometry" command.
    Note that "plugPath geometry" will be ineffectual after the first
    "wm geometry" command is issued. Also note that without gridding on the
    "wm geometry" command controls the size of the toplevel window in pixels.

6.  The packer doesn't work on the root screen (although the placer does).
    This is probably related to the hacky way I attach "." to the root
    screen. Someday I'll probably have to write a proper "root" widget, however
    this may take major interal TK hacking.
    In the meantime, the placer works perfectly well within ".".
    If you really want to map subwindows of "." use the placer.

7.  The method of grabbing icon bitmaps and importing them into TK
    is an incredibly ugly hack of tkBitmap. There really must be a
    better way. I could just ignore the use of the TK bitmap code
    and provide an iconplug widget that displays the icon provided
    by a plug widget (if any).

8.  Do we need a window handle widget? (To simulate motif completely.)

10. Some property changes may need to be tracked better. I should go down
    the property list and decide.

11. The internal Tk colormap code can still switch to "monochrome" if
    applications use a lot of colormaps. I should probably make Tkwm
    use a private colormap in such circumstances instead.
    Also, when tkwm exits, it should restore a black and white colormap.
