Version: (using KDE 4.2.0) Installed from: Gentoo Packages Setup: - focus follows mouse - xinerama, two (identical) screens - ctrl-(shift-)tab bound to "switch(/window) to next screen" When switching to the next(/other) screen and there is a window, it becomes active (when there are multiple, obviously a sensible one is chosen). However, the mouse pointer is still on the source desktop, so the focus is on a different screen than the mouse, and a subsequent use of the same action does not help in getting the focus back to the source screen. "Window to next screen works better, i.e. is easily "reversible", but I would actually like the mouse pointer to to the other screen along with the focus/window. In fact, I have two 16:10 screens and it needs quite some mouse movements to get the pointer to the focused window again.
Created attachment 31022 [details] patch against KDE-4.2.0 Patch as discussed on kde-core-devel http://markmail.org/thread/3dqy7smbpss42rp2 This moves the mouse along with the focus if "active screen follows mouse" is active. Unfortunately, I do not know much about window manager internals and/or the X11 protocol, so I cannot fix the remaining problem that due to the "focus follows mouse" setting: kwin currently contains nice code for choosing the correct client to be activated, but obviously the mouse pointer moving generates X11 events which - after the fact - let kwin choose a new window to be activated. I imagine a solution involving "simply" disregarding that event, but I do not know how much work thtat is.
Created attachment 31036 [details] patch against KDE-4.2.0, with a necessary #included added
For clarification, this has nothing to do with the focus model but whether the active screen follows mouse (kcmshell4 kwinoptions, first tab - only shown on multiscreen setups) This setting obviously atm conflicts mouse since it behaves analog to the F(S)UM policies. Altering it to the FFM behavior (only change active screen when crossing screens) would resolve this bug. Warping the pointer is probably the worst of all possible solutions.
@Martin this will either require to deactivate the shortcut for that setting (logic error) and eventually present the user a "do not show again" message or raise a notification or whatever instead or indeed warp the pointer to the screen. I like neither, so this decision becomes the maintainers take ;-)
meh Let's go from evil to not so evil: 1. wrap pointer - uh no, never 2. Deactivate shortcut - makes sense but without giving feedback it's not good 3. Do not show again - difficult. Best maybe in the code to handle the shortcut. But how? passive notification with an action? Dialog over other process? Guess passive notification with an action would be the best fit.
Git commit 7c940aa2d046e288c9ec43810269cd24a0c62fb9 by Thomas Lübking. Committed on 23/03/2013 at 20:44. Pushed by luebking into branch 'master'. block screenswitch if active screen follows mouse also inform the user about this FIXED-IN: 4.11 REVIEW: 109678 M +15 -0 kwin/useractions.cpp http://commits.kde.org/kde-workspace/7c940aa2d046e288c9ec43810269cd24a0c62fb9