Re: Cross-talk between move and maximize bindings in 1.5.3

[Teika Kazura <teika lavabit com>]

Hi. I can't reproduce the symptom reported by Derek Upham. See the
quotation at the bottom. I can't understand his theory, since I don't
know X.

By the way, I can't bind interactively to double-click. It's grabbed
as single-click, so I had to hand-edit ~/.sawfish/custom. (But the
double click works to execute a command.)

Teika (Teika kazura)

On Sun, 29 Nov 2009 19:45:48 -0800, sand blarg net wrote:
> 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.