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-8.7.6.5) 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
*** Bug 72641 has been marked as a duplicate of this bug. ***
*** Bug 65022 has been marked as a duplicate of this bug. ***
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.
*** Bug 82253 has been marked as a duplicate of this bug. ***
*** Bug 106863 has been marked as a duplicate of this bug. ***
*** Bug 110583 has been marked as a duplicate of this bug. ***
Some starting points from KWin guru (not me): kwin/events.cpp , search for 'focusPolicy', that should do and for 'enter', 'leave' and 'motion'
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.
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
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.
Why should changing virtual desktop change focus?
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?
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.
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.
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?
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.)
>------- 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.
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.
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.
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.
As I recently switched to Focus Follows Mouse and I am quite annoyed by this missing functionality I will look into this one :-)
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