Background (to frame the quandry):
In KDE, when you go to a website using firefox, the master password window appears on top of the main firefox window and it stays there, no matter where the mouse pointer happens to be, and it waits until you enter a password or cancel the password entry window. This is highly desirable.
However, when kmail is opened, the kwallet window briefly appears and then immediately slides behind the kmail window, unless the mouse pointer happens to be positioned directly over the newly appeared password entry window. This is a real nuisance.
Question:
How can I get the first behaviour as a default behaviour for all appearing password entry windows (or other windows that require input before the application canbe used)?
I think I might have just solved it. I'm not certain yet, so if you have any ideas, don't hold back ;-)
For over a decade, I have always used Focus Follows Mouse, and it is definitely very nice, when numerous application windows are open at once. You just move the mouse over to an exposed corner of an underlying window and presto! it moves to the front.
However, when a window generates a password entry window or a message window or something like that which must always stay on top until it is responded to, either by entering the password or cancelling it, then Focus Follows Mouse is not practical.
Firefox, however, seems not to honour Focus Follows Mouse with respect to the password window, but multiple opened firefox windows do follow the Focus Follows Mouse setting, so firefox is able to correctly discern the difference between notification/input windows and the application windows.
I have also played with the Focus Stealing Prevention setting, but I don't know if this might or might not help me get the effect I desire.
So, to pose the question again: Is there some combination of these or other settings that will get the desired behaviour?
On Fri, Apr 25, 2014 at 1:28 AM, Peter Gueckel pgueckel@gmail.com wrote:
For over a decade, I have always used Focus Follows Mouse, and it is definitely very nice, when numerous application windows are open at once. You just move the mouse over to an exposed corner of an underlying window and presto! it moves to the front.
IIRC Focus Follows Mouse doesn't in itself bring the window to the front, it just gives the window focus. I use this all the time but I'm travelling at the moment and can't check my other settings.
poc
On 04/25/14 08:01, Peter Gueckel wrote:
Background (to frame the quandry):
In KDE, when you go to a website using firefox, the master password window appears on top of the main firefox window and it stays there, no matter where the mouse pointer happens to be, and it waits until you enter a password or cancel the password entry window. This is highly desirable.
However, when kmail is opened, the kwallet window briefly appears and then immediately slides behind the kmail window, unless the mouse pointer happens to be positioned directly over the newly appeared password entry window. This is a real nuisance.
Question:
How can I get the first behaviour as a default behaviour for all appearing password entry windows (or other windows that require input before the application canbe used)?
I don't use kmail and can't recall if I've seen or had this problem. Or, if I had it maybe it doesn't happen that often or just doesn't annoy me.....
But, just want to know what your "Window Behavior/Focus Policy" is set to?
Ed Greshko wrote:
But, just want to know what your "Window Behavior/Focus Policy" is set
to?
I used to have it set to:
Focus Follows Mouse - Mouse Precedence Focus Stealing Prevention Low
but, although I liked the ability to control the active window by simply moving the mouse, I started to find that the password entry dialogs were not responding how I wanted, so I just recently changed to:
Click To Focus Focus Stealing Prevention Medium
I have lost that cool mouse active window control that I liked :-( but I think I am able to manage the password windows better.
I also tried Focus Stealing Prevention None, but I haven't actually observed any difference yet, so I am not sure how this setting works and if it has any effect on getting the response I want.
-
Ed Greshko -
Patrick O'Callaghan -
Peter G.