Browse all patches


Fernando Carmona Varo


If you have ever tried to use the keyboard when moving/resizing windows (by means of the move-window-interactively command) and you have set a bigger mouse-cursor-increment value to move faster (what is a need if you have not a low resolution display). You probably noticed that the window is not responsive at all, and it doesn't move when the mouse cursor does move.

This patch is intended to fix that bug. If applied, windows will follow the mouse the way it should be.

UPDATE: I was asked by Christopher to write a smooth-warp-cursor function too. I think this could be a good idea to be used for other purposes in next patches. A version of the patch including this function is here, but let's first discuss this one (I'm not very sure of making a second patch for the same file, better wait for next revision).

Patch testing[]

  1. Copy/paste the patch listed below into some file, eg. TEST.diff.
  2. If you don't have sawfish sources yet, have one, as described get it from GIT repo.
  3. Go into the directory where sawfish sources reside, eg. cd sawfish
  4. Test if the patch applies cleanly with this command:
    patch -p1 --ignore-whitespace --dry-run < TEST.diff
    in case of problems try also: -p0 or -p2
  5. If it applies cleanly, then remove the --dry-run from above command and run it again, otherwise ask on the mailing list.
  6. Compile sawfish: ./ && make
  7. Install it for testing, but it depends on your linux distribution.
    1. It is always better to install sawfish as your distribution package, but it is different for each distribution.
    2. So you may try make install, which will install sawifish in /usr/local/share/sawfish/ (if you have write access). But then make sure that you run the correct version and delete it from that directory afterwards, to avoid any conflicts.
  8. Se also

PS: edit this template if you feel that those instructions can be improved.


Index: lisp/sawfish/wm/commands/move-cursor.jl
--- lisp/sawfish/wm/commands/move-cursor.jl	(revision 4269)
+++ lisp/sawfish/wm/commands/move-cursor.jl	(working copy)
@@ -34,9 +34,21 @@
     :group misc
     :type (number 1))
-  (define (move-cursor right down)
-    (let ((coords (query-pointer)))
-      (warp-cursor (+ (car coords) right) (+ (cdr coords) down))))
+  (define (move-cursor right down #!optional (steps 5))
+    "Moves the cursor the given right and down number of pixels relative to
+the current position of the cursor. 
+A third optional argument will define the number of steps for performing the
+movement (default 5) this number must be greater than zero."
+    (let* ((coords (query-pointer))
+          (old-x (car coords))
+          (old-y (cdr coords)))
+      (do ((xstep (floor (/ right steps)))
+           (ystep (floor (/ down steps)))
+           (i 1 (1+ i)))
+          ((= i steps))
+        (warp-cursor (+ old-x (* xstep i)) (+ old-y (* ystep i))))
+      ;; Do the last step directly, to be sure it's done right
+      (warp-cursor (+ old-x right) (+ old-y down))))
   (define (move-cursor-left)
     "Move the cursor `move-cursor-increment' pixels to the left."

Community's reasons for inclusion or rejection[]

Patch submitters, please vote also! Yes, obviosuly your vote will be positive, but it's the place to give your explanation why this patch is good for all Sawfish users, and why it is correct - good reasons for inclusion.

When voting anonymously please write your name, so that it can be associated with your posts on the mailing list. If you are logged in you can sign yourself by typing four tilda characters: ~~~~.

  • Please vote with: Yes vote: yes., No vote: no., Try vote: let's try in experimental., Wtf vote: pondering. or Suspend wait for next release.
  • Wtf vote: pondering. The bug was really annoying, in my opinion. I never used sawfish keyboard moving for this reason. -Ferk(talk!) 07:35, 8 August 2008 (UTC)
can you also make a patch for smoother warp-pointer? would be really cool. Flashrider [Christopher Bratusek] 07:58, 8 August 2008 (UTC)
I think warp-cursor is "hard coded" in C, better not touch it. Warping the pointer smoothly could already be done using this same function, no need for another one, just use relative coordinates instead of absolute. But what do you want it for? hmm.. do you mean to have the animation when the mouse is warped to a focused window? that in fact could be cool. It would be a smooth "warp-cursor-to-window". Should the number of steps for mouse movement be a global variable then? -Ferk(talk!) 08:46, 8 August 2008 (UTC)
Done. -Ferk(talk!) 09:36, 8 August 2008 (UTC)
After more testing, the smooth-warping doesn't seem work very well.. also this is not a totally smooth movement (it seems that the refreshing is too fast), it just avoids the bug of the move/resize functions. I'm considering reverting the patch to the previous version (without smooth-warp-cursor). -Ferk(talk!) 09:58, 8 August 2008 (UTC)
Ok, I've reverted the changes. If someone want to see the patch that included smooth-warp-cursor, it can be checked here. Lets first discuss this patch, and if it is accepted start thinking about the later. -Ferk(talk!) 10:38, 8 August 2008 (UTC)
  • No vote: no. Spewing X requests in a loop does not feel like a sensible way to accomplish what this patch seeks to accomplish. Please find out how move-window-interactively is broken and fix it directly instead of breaking something else in the hope that the two breakages cancel each other out. Tkorvola 14:04, 8 August 2008 (UTC)
I tried that already but found no better solution. move-window-interactively waits for the event "Any-Move" to update the motion, but it seems that move-cursor fails sending the event, any idea about the reason for it? -Ferk(talk!) 16:12, 8 August 2008 (UTC)
By the way, how would you do a simulation of the mouse cursor movement? even for moving windows and drawing outlines X requests in a loop are needed. I don't think it's a breakage, outlines would also be a breakage then, they have x-draws in loop. -Ferk(talk!) 16:24, 8 August 2008 (UTC)
Normally you wouldn't want to simulate continuous mouse movement. Outlines are updated in response to actual, not simulated mouse movement, and their point is to avoid window updates even in response to actual motion events, quite the opposite of generating pointless updates (animations can be fun eye candy if you can spare the CPU cycles, but you said you were trying to fix something here, not just adding eye candy). Besides, outlines are broken, although for a different reason (server grabs suck). Tkorvola 10:49, 9 August 2008 (UTC)
I was meaning the way "x-draw" is used to draw the box outline (it makes a loop to draw all the lines that make the box) each of those loops is a response to a mouse movement. On the other hand, this patch makes a loop (only 5 calls, while box outline make 8) in response to a non-simulated key-press (key-presses normally have less frequency than the movement of the x/y axis of a mouse). I don't think this is slow at all (in fact in my computer it is so fast that is hard to see). Anyway, do you think it would be a good idea to make the steps be a global variable?. If it's set to 1 it would be meaningless, no loop.
However, I think that we should discuss the patch based on what it can be useful for, in every aspect. I don't really care if the fix of the bug is a side effect or the main scope. I wrote the synopsis based on what has driven me to write this patch, but I think it is the code what should be judged. Would the same code with a different synopsis make any difference? -Ferk(talk!) 11:43, 9 August 2008 (UTC)
Well.. but I also understand what you mean. And I agree that this is a dirty fix for the bug (it fact it doesn't solves it completely, but it is an improvement, the window is in fact more responsive to keypresses, although sometimes not pixel-precise). It is probably a problem of "grab-pointer". However.. this may work as temporal fix and at the same time may provide the start for a new feature (smooth mouse cursor movement for all those warpings). -Ferk(talk!) 12:30, 9 August 2008 (UTC)
That feature seems worse than useless. If one would like to animate pointer warping to look smooth, one would fake it so that it only looks smooth without the pointer really passing through windows that happen to lie in the way and triggering events. Tkorvola 09:29, 10 August 2008 (UTC)
Ok, you are right. I changed my vote. I hope there's a better way to fix the problem. -Ferk(talk!) 02:31, 11 August 2008 (UTC)
Sorry for the big delay (I'm so busy). I've been thinking and I still believe that this patch was not such a bad idea. Sometimes I do want my keypressed movements to move "passing through windows" and "triggering events". It is a movement simulation after all. The movements of a real mouse would also trigger events in the way. If I have a big value for move-mouse-increment it will warp instead of triggering the events in the middle, which is a buggy behavior if we really want to simulate a mouse movement by keyboard. I don't think that there's a better fix that doesn't reintroduces new problems or new complexity. --Ferk(talk!) 19:18, 14 February 2009 (UTC)
  • No vote: no. As there are only negative votes and the discussion leads to such conclusion - I'm rejecting this patch (as requested by submitter). If you ever happen to implement this in another way - do not hesitate to submit it again in better form :) Janek Kozicki 16:30, 17 September 2008 (UTC)