[kwin] [Bug 361940] In focus follows mouse mode, the window under the pointer sometimes does not have focus
https://bugs.kde.org/show_bug.cgi?id=361940 --- Comment #33 from Bob Farmer --- Tried working around this by switching to "Focus Follows Mouse - Mouse Precedence" and setting some "Focus stealing prevention", but even that doesn't work. At a prevention level of "Medium" and delay of 25 ms, problem still happens regularly enough. Focus stealing prevention modes above "Medium" are unusable, because they break apps (I can't even use the KDE Launcher at "High" or "Extreme"). It seems the only way to make focus-follows-mouse work properly in KDE currently is by setting a ridiculously long delay. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 361940] In focus follows mouse mode, the window under the pointer sometimes does not have focus
https://bugs.kde.org/show_bug.cgi?id=361940 --- Comment #32 from Bob Farmer --- Update: even with 25 ms delay, this problem still happens occasionally. I'm guessing it all depends on how fast you're moving the mouse cursor and how long it takes the traverse the other windows you're moving past, on your way to your final destination. This has made KDE frustrating to use. Is there any hope for a fix in the near future? My comment #31 makes it extremely easy to reproduce on demand. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 325286] snap-to-client vs snap-to-deco should be configurable
https://bugs.kde.org/show_bug.cgi?id=325286 --- Comment #94 from Bob Farmer --- For those who care, I've uploaded a KDE5 version of the snap-to-deco script that Thomas Lübking originally posted in comment #40 (as he's told me he won't be updating it himself): http://www.kde-look.org/p/1135334/ It fixes two new KDE5 problems that I ran across with the script: broken configuration dialog, and newly-placed windows not being snapped properly (if applicable based on your placement policy...) -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 361940] In focus follows mouse mode, the window under the pointer sometimes does not have focus
https://bugs.kde.org/show_bug.cgi?id=361940 --- Comment #31 from Bob Farmer --- If I get rid of the xterm windows, and use 2 Firefox windows and 1 Thunderbird window (Firefox -> Firefox -> Thunderbird, with the middle Firefox being a small sliver in the background), then it becomes extremely easy to reproduce. The problem happens 50%+ of the time, kind of crazy in fact. (This is with FSUM and 0 ms delay) 10 ms makes it a lot less common, 20 ms makes it pretty rare but still seen it happen. Haven't been able to reproduce with 25+ ms yet. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 361940] In focus follows mouse mode, the window under the pointer sometimes does not have focus
https://bugs.kde.org/show_bug.cgi?id=361940 Bob Farmer changed: What|Removed |Added CC||k...@bfarmer.net --- Comment #30 from Bob Farmer --- I've been seeing this bug quite regularly since moving from 4.14 to 5.6.5. With my usual settings (Focus Strictly Under Mouse and 0 ms delay) it's extremely easy to reproduce. Put 2 xterm windows near each other with a small gap, then put a Firefox window in the background in that gap. Move your mouse back and forth between the 2 xterm windows quickly and eventually (5-10% of the time?) you'll find that the focus isn't under your mouse, even though you're using "Focus Strictly Under Mouse"...the focus will be on the small sliver of the Firefox window inbetween the two xterm windows. If I switch to "Focus Follows Mouse - Mouse Precedence" mode, and no Focus stealing prevention, it's still easily reproduceable. With this new mode, though, I have the option of turning on Focus stealing prevention, and when I set that to "Low" it becomes extremely hard to reproduce (and occasionally the Firefox entry in the taskbar gets highlighted red - I guess this means a focus "steal" was prevented?) Going back to my preferred mode, "Focus Strictly Under Mouse", and then setting a delay of 20 ms also made it very hard to reproduce (or maybe impossible, haven't seen it yet...) So, maybe the short delay is the way to go, unless/until this is fixed. By the way, I wasn't able to reproduce this with 3 xterms, had to have a Firefox window involved. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 347176] kcm_kwin4_genericscripted.so not found because it's in the wrong location
https://bugs.kde.org/show_bug.cgi?id=347176 Bob Farmer changed: What|Removed |Added CC||k...@bfarmer.net --- Comment #22 from Bob Farmer --- If you're trying to fix this in an already-installed script, what I discovered is that there was a second .desktop file corresponding to the installed KWin script, inside: ~/.local/share/kservices5/ In Marc's comment #17 he implied that he was only editing the path for kcm_kwin4_genericscripted in his metadata.desktop file inside ~/.local/share/kwin/scripts/XXX/ After updating the path to "kwin/effects/configs/kcm_kwin4_genericscripted" in both locations, things work fine for me. -- You are receiving this mail because: You are watching all bug changes.
