The Joy of Window-Override-Redirect

[Timothy.Freeman@PROOF.ERGO.CS.CMU.EDU]

Here's a nead hack.  I didn't see uses of this in the Clue code I
recently fetched from csc.ti.com, so maybe someone out there will have
a use for this.

I just figured out what window-override-redirect is good for.  You
have to use it if you want to correctly cache the width and height of
windows on the client side of the connection.  Before my application
did this, I found that it was spending most of its time running back
and forth to the server getting the widths and heights of windows.
Here's comment I inserted into my code to explain things.

;;; X11 resize wonders:
;;; We have to keep the shape of the window cached in the window
;;; somewhere, because we ask for the shape of the window very often,
;;; and if there's a round trip to the server for each request, we
;;; spend most of the time figuring out the sizes of our windows.
;;;
;;; So we do the obvious thing: when we resize our windows, we stash
;;; the new width and height in instance variables, and redefine
;;; drawable-width &co to deal with these instance variables.  The
;;; class optimize-drawable-width-height deals with this.
;;;
;;; The problem comes when the window manager can resize our top level
;;; windows.  We ought to get an event that says to update the stashed
;;; width and height.  There isn't normally an event that means "Someone else
;;; resized your window"; the choices are to receive configure-notify
;;; events or to play with resize-redirects.
;;;
;;; Receiving configure-notifies is analogous to what we did in X10.
;;; The problem is that we will receive configure-notifies for any
;;; resize of the window, whether we decided to do the resize or the
;;; window manager decided to do the resize.  By keeping track of our
;;; own resizes, is possible to correctly guess most of the time which
;;; resizes are due to our behavior and which are due to the window
;;; managers, but the code was a pain to write and is ugly (see div.lisp).
;;; It was even worse under x10, since both resizes and exposures
;;; looked like exposure events.
;;;
;;; So, the ideal solution is to turn on resize-redirect on each
;;; window.  Resize-redirect allows this process to resize its own
;;; windows without any problems, but when the window manager resizes
;;; a window, the only thing that happens is we get a resize-request
;;; event.  So, when we get a resize-request event, we should resize
;;; the window to whatever the window manager wants, and update our
;;; idea of the shape of the window appropriately.
;;;
;;; This almost works.  The bug is that when we resize the window the
;;; way the WM wants, the WM sees our resizing, and then it tries to
;;; fit the window to our resizing by resizing the frame that has the
;;; title bar.  This has the side effect of resizing our window to the
;;; size it already is, and then we get a resize-request, and we
;;; resize our window, ... and we loop.
;;;
;;; So, the trick is for us to do our resize without the WM noticing.
;;; Before the resize, we set window-override-redirect for the window
;;; to :on, and after our resize, we set it to :off.  This works.