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, [email protected] 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.
