(*** This bug was imported into bugs.kde.org ***) Package: kwin Version: KDE 2.2.1 Severity: wishlist Installed from: Mandrake RPMs Compiler: Not Specified OS: Not Specified OS/Compiler notes: Not Specified I really like using the "focus follows mouse" focus policy but pop-up windows cause a problem. Having new pop-ups grab focus helps the first part of the problem but if I'm at a Konsole type "nedit somefile.txt" execute some command in NEdit that opens a new dialog and then close that dialog then Konsole gets focus back instead of NEdit since the mouse pointer is over Konsole. What I'd like to see is a toggle (in addition to the current focus policies) for "Mouse follows focus". Enabling this feature would warp the mouse pointer to new windows as they get focus. In conjunction it would be good to have a short history (maybe 5 entries or so) of where the focus has been so that say killing an NEdit pop-up that ended up over Konqueror returns the focus/pointer to NEdit. Thanks -Nathan (Submitted via bugs.kde.org)
My original request: """ What I'd like to see is a toggle (in addition to the current focus policies) for "Mouse follows focus". Enabling this feature would warp the mouse pointer to new windows as they get focus. In conjunction it would be good to have a short history (maybe 5 entries or so) of where the focus has been so that say killing an NEdit pop-up that ended up over Konqueror returns the focus/pointer to NEdit. """ Sawfish has this feature by the way. It's tremendously useful when you're on a laptop and using the mouse is even less desirable than normal. Desire for this even led me to switch to gnome for a while though other issues brought me back to KDE. Cheers -Nathan -- >>>-- Nathaniel Gray -- Caltech Computer Science ------> >>>-- Mojave Project -- http://mojave.cs.caltech.edu -->
*** Bug 29219 has been marked as a duplicate of this bug. ***
*** Bug 46245 has been marked as a duplicate of this bug. ***
Created attachment 976 [details] Mouse-follows-focus patch This patch adds the requested feature to kwin, as well as a configure option to the configuration module (default off). It does not implement a position history.
Thanks for working on this! The patch is a good start, but it's too aggressive. Now any time the mouse crosses into a new window it gets warped into the center of that window, which is very disconcerting. Not only that, but if you have a small window A over the center of a large window B and you move the mouse into window B it will warp to be over A. Then the pointer becomes trapped in window A, because any time you move it out of A it enters B and gets warped back into A. The mouse warping should only happen when focus changes because of: 1. a popup dialog appearing or disappearing. 2. alt+tab It might work to say the mouse should only be warped when focus is grabbed by a window that the mouse pointer is not currently in. And some care needs to be taken to ensure the pointer doesn't end up above some window that's in front of the one that should get focus. The way sawfish does this is to raise the target window to front, which seems like a good solution to me. Again, thanks!
Using your patch as a guideline I implemented this so that it only warps the pointer after Alt-Tab. I also moved the configuration toggle to the Navigation section. I've tried it with different focus policies in KDE/CDE modes (there should be better names for those--I had no idea what they did until now) and it works well. My patch is against the kdebase package from KDE 3.1. I'm really happy to have this feature, and I hope you'll commit the patch! Cheers!
Created attachment 983 [details] Patch to warp mouse on alt+tab
Created attachment 990 [details] Patch to warp mouse on alt+tab My last patch did not work 100% of the time in KDE window traversal mode. This one seems to be much more solid. It could, of course, use additional testing. Again, it's a patch against kdebase-3.1
I just wanted to mention that I've been using the last focus-follows-mouse patch for the last two months and it works really well without any problems. Is there any hope of getting this applied? Thanks.
I would really like to see this feature in the new kde 3.4. I think this nice feature has been overlooked even though this bug report is already very old and started in KDE 2.2.1. Further I would like to add that this feature is also very important when you're using the hotkeys feauture, or do application switches which walk through desktops. Very annoyingly this causes very often the wrong application to be focused (because the x,y coordinate of the mouse pointer was not in the appropriate postion and somehow the "Focus follows mouse" policy raises the wrong window.)
Will this tab also work if I'm using a key combination other than Alt-Tab to cycle windows?
Personally I consider the programmatic change of the mouse cursor as something very evil. Because of this I don't expect that we will implement this feature request. I am sorry that this feature request could not be added to kwin at the time when the patches applied to the source code. I want to thank you for both the feature request and the patches.
Subjective opinions about "evilness" are not very useful unless backed up with facts and logical reasoning ;) Personally I switched away from kwin several years ago. I don't mean to sound rude (especially when the previous comment was so polite) but this bug has taken over 10 years to go from NEW to WONTFIX, which suggests the kwin project badly needs a new approach for handling bugs.
Martin is currently cleaning up rotten bugs, bug handling got quite some improved since he maintains kwin. Now, here comes ratio: - Warping the pointer breaks pen and touch devices (separating input device and pointer positions) - Warping the pointer is invasive just like someone would take your hand and force it somewhere else - Warping the pointer on top of a just showing up window, above a UI element where you don't know what happens if the user clicks leads to unforeseeable consequences Warping pointer is considered evil, that's -not only- a subjective opinion, but common sense. You just don't unless it is *really* (REALLY) required. Aside this, FFM follows the general focus list, so usually the focus should go from a nedit dialog back to nedit, if nedit had the focus right before, we extra added a way to prefer the window under the mouse instead because of another wish and in this context also had a short discussion about the option to accomplish that by warping the pointer to the focused window. Regardless of this bug.