|Summary:||JJ: change focus only when moving mouse|
|Product:||[Plasma] kwin||Reporter:||Janis Blechert <janis.blechert>|
|Component:||core||Assignee:||KWin default assignee <kwin-bugs-null>|
|Severity:||wishlist||CC:||anthony, cdauth+bugs.kde.org, dave+kde, ewan.dunbar, gamaral, matt, wmertens, woebbeking|
|Latest Commit:||Version Fixed In:||4.9|
Hope this is up to par
Description Janis Blechert 2004-10-29 00:56:22 UTC
Version: unknown (using KDE 3.3.1, Gentoo) Compiler: gcc version 3.4.2 (Gentoo Linux 3.4.2-r2, ssp-3.4.1-1, pie-18.104.22.168) OS: Linux (i686) release 2.6.9-nitro2 This regards 'focus follows mouse' in control center -> Desktop -> Window Behavior. The problem is quite simple, I think the focus should only be changed if the mouse was moved, normally this is no problem since the window under the mouse won't change but for example when changing from fullscreen to normal it is quite annoying if the focus was changed to some other window (whereever the mouse is now) even though I did nothing to change the focus. There might be other situations in which this could happen but I can't think of any
Comment 1 Lubos Lunak 2004-10-29 14:16:31 UTC
*** Bug 72641 has been marked as a duplicate of this bug. ***
Comment 2 Lubos Lunak 2004-11-19 19:15:03 UTC
*** Bug 65022 has been marked as a duplicate of this bug. ***
Comment 3 ewan dunbar 2004-12-06 23:20:20 UTC
yes, at least one other case, borrowed from 65022 which is marked as a duplicate of this bug: do the following in a mouse focus mode: find a letter which, when typed into the Run Command dialog, will pop up a dropdown box so long that it extends outside where the dialog itself is. clear the run command dialog from the screen if you had it open, but make sure your pointer is in the area on the screen where the dropdown box will hypothetically extend. open a window that fills the screen. use a keyboard shortcut to bring up the Run Command dialog. type an appropriate letter. when the autocomplete appears, hit escape. focus will be on the big window.
Comment 4 Lubos Lunak 2005-06-17 15:37:38 UTC
*** Bug 82253 has been marked as a duplicate of this bug. ***
Comment 5 Lubos Lunak 2005-06-22 16:56:15 UTC
*** Bug 106863 has been marked as a duplicate of this bug. ***
Comment 6 Lubos Lunak 2005-08-13 21:32:07 UTC
*** Bug 110583 has been marked as a duplicate of this bug. ***
Comment 7 Andre Woebbeking 2006-04-13 00:00:53 UTC
Some starting points from KWin guru (not me): kwin/events.cpp , search for 'focusPolicy', that should do and for 'enter', 'leave' and 'motion'
Comment 8 jlh 2007-05-31 13:59:45 UTC
This problem also affects the 'pack shortcuts' feature, rendering them quite unusable to move windows around with the keyboard. Any shortcut that changes the window size and/or position should never make it lose focus.
Comment 9 Guillermo Antonio Amaral Bastidas 2007-06-11 07:28:59 UTC
Created attachment 20831 [details] Hope this is up to par This is the cleanest I could get it, hope I understood correctly. :) any comments or tips are welcome
Comment 10 jlh 2007-06-12 13:10:18 UTC
Created attachment 20840 [details] Proposed patch Your patch only made this work sporadically, because last_mouse_pos didn't get updated often enough. Here's a new patch that works very well for me so far. It doesn't change focus if the mouse position and active desktop haven't changed. I can now move windows around with the 'pack' shortcuts and also unmaximize a window without making it lose focus. The behavior for "strictly under mouse" focus policy is unchanged. It doesn't fix the problem described in comment #3 however. This patch is for KDE 3.5.5 (my apologizes, I'm scratching my own itch here), but I noticed it even applies (with some offsets) to the trunk, however I didn't build it to test.
Comment 11 Lubos Lunak 2007-06-12 17:49:13 UTC
Why should changing virtual desktop change focus?
Comment 12 Andre Woebbeking 2007-06-12 23:50:30 UTC
On Tuesday 12 June 2007, Lubos Lunak wrote: > Why should changing virtual desktop change focus? Wouldn't it be strange that a not visible widget keeps focus?
Comment 13 Lubos Lunak 2007-06-13 11:38:37 UTC
It of course wouldn't. E.g. the previously active window on that desktop could be activated, like with click to focus. I'm simply asking because I don't use mouse focus policies - since this patch makes focus follows mouse act more like click to focus WRT keyboard shortcuts, I though it should in this case as well.
Comment 14 jlh 2007-06-13 15:06:29 UTC
In "click to focus" mode, the focused window will be remembered on each desktop and that focus will be restored whenever you come back to any desktop. So you propose this behavior to be the same in "Focus follows mouse" mode, correct? That might or might not be what people want, but it's definitely a very interesting idea (I'd use that actually). However, I think this is a different issue than what we try to fix here. I found a potential prolem with my patch: When you lower a window with the keyboard, it will stay focused (since the mouse hasn't moved). Now, this can be good or bad. Either you lowered it and want to raise it right after again (to quickly see under the window), in which case it should stay focused. Or then you lowered it to switch to the next window just beneath, which I do often, in which case you would want the new window to get the focus. Either behavior could or could not have been what the user wants.
Comment 15 Lubos Lunak 2007-06-13 16:17:47 UTC
The case with lowering is similar to desktop switching - people might or might not want it. However I'd expect that not changing the active window in such case should be better, since going to the other option in such case should be as simple as clicking to activate the window, while the other way around it would be more complicated. Would that be ok?
Comment 16 jlh 2007-06-13 17:24:26 UTC
That would be ok for me. For even more keyboard-comfort, maybe there could be a new shortcut meaning "focus window under mouse", similar to what a click would do. It wouldn't be useful in all situations, but in some it would. Or maybe "focus top-most window". But I haven't thought much about it yet. I just found out I can now shade and unshade a window to quickly peek at what's behind it, instead of lowering/re-raising. Very useful too, but it some rare situations it doesn't work properly. It might be necessary to re-write that patch in a cleaner way. (Instead of prohibiting focus change when it's not wanted, prohibit by default and allow when it's wanted.)
Comment 17 Guillermo Antonio Amaral Bastidas 2007-06-14 09:25:34 UTC
>------- Additional Comment #10 From jlh 2007-06-12 13:10 ------- > >Your patch only made this work sporadically, because last_mouse_pos didn't >get >updated often enough. I did try something similar to your patch but I noticed that the move messages where only sent when the mouse was moved over the border of the window so I decided to keep it simple.
Comment 18 Lubos Lunak 2007-06-21 16:59:31 UTC
Created attachment 20919 [details] kwin patch Please test this patch (KDE3). It is based on the patch from comment #10, with the change from comment #15 and also it fixes issue from comment #3.
Comment 19 jlh 2007-06-21 22:32:55 UTC
Thanks, I'm trying that patch now and it looks almost good to me. I confirm that the problems from comment #15 and comment #3 work fine, but there's a situation similar to #3 that fails: 1. Have any window maximized. 2. Place your mouse cursor as in comment #3. 3. Open the run window. 4. Move the mouse slightly (a few pixels). 5. Type a letter that makes the drop down box extend beyond the run window where the mouse is ('k' is often a good choice). 6. Delete the typed character so the drop down closes. 7. The window beneath will get focus. This is the same as #3 excepted for the added step 4. (Similarly, instead of moving the mouse between 3. and 5., you can also move it between 5. and 6.) Maybe this is too pedantic to be worth also fixing, but it's counter-intuitive that a meaningless mouse move changes the behavior.
Comment 20 Lubos Lunak 2007-08-24 11:42:08 UTC
That would require changing how the code remembers when to allow changing focus, from position to window, and I don't have time for that now. I'll commit at least this version, so that there's at least some fix, the rest somebody or somewhen later.
Comment 21 Martin Flöser 2012-04-08 19:13:13 UTC
As I recently switched to Focus Follows Mouse and I am quite annoyed by this missing functionality I will look into this one :-)
Comment 22 Thomas Lübking 2012-04-17 19:28:32 UTC
Git commit 8e544efab3d70ae1e1570bff28e78f58f52a177f by Thomas Lübking. Committed on 16/04/2012 at 18:42. Pushed by luebking into branch 'master'. store focusMousePosition on unmapNotify events FIXED-IN: 4.9 REVIEW: 104620 M +1 -0 kwin/events.cpp http://commits.kde.org/kde-workspace/8e544efab3d70ae1e1570bff28e78f58f52a177f