Version: (using KDE KDE 3.1.94) Installed from: Compiled From Sources Behaviour: - Set Focus Follows Mouse - Put a window in the center of the screen - Put the mousecursor below center so that the mini-cli will not cover it but it is still in the window - press alt-f2, mini-cli comes up - type 'h'. Command completion will pop up a list that most probably extends beyond the mini-cli (if you type http a lot :) ). Make sure the mouse is in this list, but not in the mini-cli - continue typing some letters, list disappears - => Presto, focus is now in window. So, I guess the general behaviour is something like "Transient windows should revert focus to last window" or something like that. Please fix this, it's very annoying :)
Hard. If ever a way is found to distinguish EnterNotify events caused by user from those caused by window structure changes, the focus stealing prevention problem from bug #76716 could be fixed as well (explicit updateUserTime() on activation by user EnterNotify).
Ok, I can see that this goes back to the X11 event policies. How about tying EnterNotify events to time since window structure change? If you get an EnterNotify shortly after a window was unmapped, you can decide that it was because of the unmapping, especially when the mouse pointer is in the rectangle that was occupied by that window. In that case, you revert focus to the last window, not the one that got EnterNotify. Another way of going about it in this specific case would be to make the "Run Command" dialog modal, and refuse to lose focus until unmapped. Maybe as an advanced configuration option? What do you think?
Updating to retain visibility
*** This bug has been marked as a duplicate of 92290 ***
testing, ignore On Wednesday 14 of January 2004 15:38, Wout Mertens wrote:
test2, ignore On Wednesday 14 of January 2004 15:38, Wout Mertens wrote:
test 3 On Wednesday 09 of March 2005 17:01, Lubos Lunak wrote: [bugs.kde.org quoted mail]