To understand a window manager in any kind of detail, you pretty much
have to read:
  ICCCM 2.0 (sections 2.8, 4):
    http://tronche.com/gui/x/icccm/
    ftp://ftp.x.org/pub/X11R7.0/doc/PDF/icccm.pdf
      (Warning, the HTML version at least contains errors in various
      structure definitions.)

  EWMH:
    http://standards.freedesktop.org/wm-spec/wm-spec-latest.html
    http://webcvs.freedesktop.org/icccm-extensions/wm-spec/wm-spec.xml?view=log
      (The preformatted version is not always as up-to-date as the CVS
      version, even if it calls itself "latest".)

  X protocol spec:
     ftp://ftp.x.org/pub/X11R7.0/doc/PDF/proto.pdf
     http://en.wikipedia.org/wiki/X_Window_core_protocol

     There appears to be a (illegal?) copy of the O'Reilly Xlib
     programming manual at:
       http://www.sbin.org/doc/Xlib/
     This book does not seem to be available through O'Reilly Safari.
     It has more detailed explanations of some concepts -- useful when
     you are going "so I read the spec and I know what all the words
     mean but still have no idea what they were trying to do".

     You should understand the basic ideas of events, requests,
     errors, windows, event masks, atoms, properties, and
     SubstructureRedirect (the one key piece of magic around which the
     concept of "window manager" revolves).

  X extension specs:
     Xdamage:
       http://gitweb.freedesktop.org/?p=xorg/proto/damageproto.git;a=tree
     Composite: 
       http://gitweb.freedesktop.org/?p=xorg/proto/compositeproto.git;a=tree
     XFixes:
       http://gitweb.freedesktop.org/?p=xorg/proto/fixesproto.git;a=tree

     These are only necessary if dealing with compositing code
     directly, really.

  There also exist MWM hints, de facto standard hints introduced by
  Motif.  These are poorly documented, but it looks like basically,
  they let a window say whether or not certain operations should be
  allowed on it -- similar to _NET_WM_ALLOWED_ACTIONS, except a
  request from a client rather than information from the WM -- and
  some hints about decoration -- should it have a border, what sort of
  buttons should it have, etc.  AFAICT these are all totally
  uninteresting to us.

  Then there's the oral tradition, including things like
  _NET_WM_WINDOW_OPACITY...

X and in particular ICCCM are famous for being absolutely nasty.  This
is somewhat true, especially if you try to really get into all the
details of X visuals, etc., but overall I found them disappointingly
straightforward.  I suspect their reputation stems from a kinder,
gentler era before programmers had become acclimated to standards
like, say, XML.


Random notes on pieces of these:

Windows are always positioned in their parent's coordinate space; the
coordinate given is where the upper-left corner will be located.

Gravity is basically about resizing.  "Bit gravity" is, if the window
is resized, which part of its contents should be preserved.  "Win
gravity" is, if the window's parent is resized, how should the
contained window be moved (which point should remain at constant
position relative).  WM gravity hints say (on initial map) how the
window should be moved relative to its requested position to make room
for window decorations, and on later resizes, they say if the size
alone is changed, then which point on the window should remain at a
constant position while everything else stretches/shrinks around it.

Places where the specs simply do not apply in the way they want to,
because we violate their assumptions:
  -- pretty much all the gravity stuff, because we control position
     absolutely
  -- similarly, all the stuff about which sort of position requests
     should be honored or not (USPosition vs. PPosition, EWMH source
     indication, etc.), because we're not going to honor any of them.
  -- We might want to honor some stacking requests (raise/lower stuff)
  -- Our notion of iconified is somewhat bizarre
  -- Not clear what _NET_FRAME_EXTENTS means for a tiling WM...
  -- EWMH desktop stuff will need some work.  _NET_DESKTOP_LAYOUT will
     just be ignored.  We might want to support _NET_DESKTOP_NAMES,
     but make it readonly for everyone else -- e.g., if a pager tries
     to change it, notice and change it back.  
  -- If/when we get multiple viewport (xinerama) support, the EWMH
     desktop stuff becomes even more useless -- _NET_CURRENT_DESKTOP
     does not make sense when there are multiple desktops.
     _NET_DESKTOP_GEOMETRY does not make sense when there are multiple
     sizes.  What to do?
