Bug 183410 - "Switch to next screen" shortcut conflicts with "active screen follows mouse"
Summary: "Switch to next screen" shortcut conflicts with "active screen follows mouse"
Status: RESOLVED FIXED
Alias: None
Product: kwin
Classification: Plasma
Component: xinerama (show other bugs)
Version: unspecified
Platform: Gentoo Packages Unspecified
: NOR normal
Target Milestone: ---
Assignee: KWin default assignee
URL: https://git.reviewboard.kde.org/r/109...
Keywords:
Depends on:
Blocks:
 
Reported: 2009-02-06 11:41 UTC by Hans Meine
Modified: 2013-03-28 19:31 UTC (History)
0 users

See Also:
Latest Commit: http://commits.kde.org/kde-workspace/7c940aa2d046e288c9ec43810269cd24a0c62fb9
Version Fixed In: 4.11
thomas.luebking: Decision-Required+
thomas.luebking: ReviewRequest+

Attachments
patch against KDE-4.2.0 (2.70 KB, patch)
2009-02-06 13:08 UTC, Hans Meine 		Details
patch against KDE-4.2.0, with a necessary #included added (2.91 KB, patch)
2009-02-06 15:12 UTC, Hans Meine 		Details
Show Obsolete (1) View All Add an attachment

Note You need to log in before you can comment on or make changes to this bug.
Description Hans Meine 2009-02-06 11:41:51 UTC 
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.
Comment 1 Hans Meine 2009-02-06 13:08:13 UTC 
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.
Comment 2 Hans Meine 2009-02-06 15:12:34 UTC 
Created attachment 31036 [details]
patch against KDE-4.2.0, with a necessary #included added
Comment 3 Thomas Lübking 2012-03-11 23:55:07 UTC 
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.
Comment 4 Thomas Lübking 2013-03-22 23:27:23 UTC 
@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 ;-)
Comment 5 Martin Flöser 2013-03-23 10:22:37 UTC 
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.
Comment 6 Thomas Lübking 2013-03-28 19:31:35 UTC 
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