Cross-talk between move and maximize bindings in 1.5.3

[sand blarg net]

I use the following bindings in Sawfish:

  "A-Button1-Move"   move-window-interactively
  "A-Button1-Click2" maximize-window-toggle

Holding down the Alt key and mouse button 1 and dragging anywhere in a
window or its frame moves the window.  Holding down the Alt key and
double clicking mouse button 1 anywhere maximizes or unmaximizes the
window.

With version 1.5.3, there is a bad interaction between the two
bindings with the new warp-to-window feature at unmaximize time.

1. Set up the bindings:

    (bind-keys window-keymap
               "A-Button1-Move"   'move-window-interactively
               "A-Button1-Click2" 'maximize-window-toggle)

2. Bring up some window that can be sized to roughly 1/4 of
the screen.  I use xmessage, and stretch it.  Move it to the
bottom-right corner of the screen.

3. Maximize the xmessage window by any means.

4. Move the cursor to the bottom-left quadrant of the screen, such
that it is (a) just to the left of the original location of the
window, and (b) much lower than the top of the original location of
the window.

5. Hold down the Alt key and double-click with mouse button 1 to
unmaximize the window.

For me, the window unmaximizes, the cursor warps to the expected
"origin" location of the xmessage window, and *the xmessage window
shifts upwards to maintain the relative position of the cursor*.  If
the cursor is 50 pixels from the bottom of the screen (and the bottom
of the original xmessage window), then the cursor warps to the
original xmessage window origin and the unmaximized xmessage window
moves up such that the pointer is once again 50 pixels from the bottom
of the window.  (Your behavior may vary, as I have custom "hard
boundaries" support enabled; move your mouse too far to the left and
your xmessage window might get pushed all the way off the screen.)

This appears to be a bad interaction between the two bindings.  The
first click sets up internal state for moving the window.  The second
click begins the unmaximization process.  The warping adjusts the
cursor position, and then the move teardown process adjusts the window
position to match the updated cursor position.  I suspect that this
problem has been in the code for years, but it wasn't noticeable
because the code didn't warp the cursor on unmaximize until now.  (On
maximize, warping is never necessary.)

So we need to fix the event handling, such that all movement work ends
once we go to the double-click.

I would also appreciate it if we could make the warping optional, by
wrapping it in a window-warp-when-unmaximized test---I'd rather not
warp the cursor in any case, even with the long-term fix.  Of course,
that variable would work as a short-term fix for me as well, until the
event problem is fixed.

Thanks,

Derek

-- 
Derek Upham
sand blarg net