Version: (using KDE KDE 3.5.3) Installed from: SuSE RPMs OS: Linux KDE Settings: Focus Follows Mouse Auto raise off Delay focus off Click raise active window off Single-click (no double-click) I've tried this with a new user as well. Problem description: (way to reproduce as well) 1. Open a directory with mp3:s 2. Click on an MP3.- Audacious opens, starts playing. (Same with xmms - can it be programs without window borders?) 3. See to it that the player window opened partially over konqueror's window. (If necessary, move it, and close to make it save the settings. Then do (2) again.) 4. Click in the konqueror window beneath Audacious/xmms. (E.g. on a file). What happens now is that konqueror's window pops to front. This only happens the first time - Get Audacious to front and repeat the click, and it will work as it should. This is quite annoying, as I often start audacious by clicking on an mp3, and then I want to drag some more mp3's to the play list, and konqueror pops to front instead!
Created attachment 17547 [details] A picture showing how to place the windows.
Do you stil have this problem with recent version of kwin?
Hello, I just tested. The problem is still there in KDE 4.2.2, in both Konqueror and Dolphin (and audacious). Now that I think about it again, I've noticed similar effects at odd times that I have not investigated in the same manner. I'm also using Kubuntu now (used SuSE back when I reported the bug), so it's not distribution specific.
I think this is not a bug: the second time you click on the mp3 file, the command called for reproduce it doesn't start a new audacious/xmms istance but it append the file on the playlist so this behaviour looks correct and consistent to me.
it's a bug - the dolphin should never raise. it does however work w/o focus delay here. the reason is that the focus is passed onto audacious (or whatever) when clicking the mp3 (@staffan: please confirm this since i did not try w/ audacious) and a) kwin raises INactive windows on click b) since the mouse does not mystically "re-enter" dolphin, it won't get the focus back with "follows mouse" in general this bug is valid.
I just tested in KDE 4.5.2, and can confirm that the bug is still there. It's over four years since I originally reported this. ;-) I just noticed an interesting thing when trying to check what you write: No window is active for after clicking an mp3 the first time. Checking all steps of the process to reproduce this: 1. After I've opened a window with mp3's, it is active (blue border in the taskbar). 2. After I click an mp3, audacious opens up, and the blue border in the taskbar disappears. Now, there are two scenarios: 1. While keeping the mouse over the dolphin window, click on another mp3, and the dolphin window gets raised. 2. Move the mouse pointer over a few windows and then back above the dolphin window. Now the dolphin window is active again. Click on another mp3, and everything works as it should! So, I think the real problem is that after audacious starts, we get into a situation with no active window! Does this help?
The two scenarios I listed are, of course, two alternatives. Do the first two steps, and then do either 1 or 2. To test the other alternative, start over from the beginning.
whether no window or another window has the focus does actually not matter. however as a workaround you could alter the behaviour of inactive windows from "activate, raise & pass click" to "activate & pass click" ("kcmshell4 kwinoptions", "window actions" tab) since i first thought this might be a contradiction, a possibly resolving behaviour would be: a) you doN'T want active windows to raise on click b) (assumed) you DO want INactive windows to raise on click c) you want new windows to (at least be allowed to) take the focus ("get active") d) if c) happened, you do not want b) to happen for the previously active window but i guess that behaviour might be controversal, so it would require another option...
I actually have "Click raises active window" off. I never want to raise a window when I click in it (except for when I click on the window border). I didn't know there was another similar option for inactive windows. What I've always wanted is for the window _not_ to raise on click, no matter if the window is active or inactive. I've now changed the setting to "activate & pass click". Now the problem is gone! Using focus-follows-mouse, it's normally impossible to click in an inactive window. As you move the mouse pointer to the inactive window, it changes to active before you have a chance to click in it. :-) Thanks for the help! This probably solves other annoying problem of windows sometimes getting raised on click. Now this makes me wonder.. Maybe the options should be linked? I.e. if I have chosen focus-follows-mouse, and "click does not raise active window", "click does not raise _inactive_ window" should be automatically selected. Or, at least giving the user information about it. I don't think anyone wants inactive windows raised on click if he/she doesn't want active windows raised on click (especially when using focus-follows-mouse).
a) closing as "works for me" since what you want is actually supported (and has been ;-) and the other thing is such a farcornercase that it's not worth to bloat the code unless there's at least explicit request for such behaviour b) i'm not in the position to decide the linking, but my opinion: yesno. - linking for "f-f-m" isn't valid because there's the delay option. - linking unless delay is used might be valid but not sufficient (cause then you'd still experience this problem with enabled delay) - while the general assumption "active || !inactive" makes sense it's also an artificial restriction (and a behavioural change...) * i however guess a little hint text might not hurt a all ;-) (maybe changing the checkbox could automatically alter the setting, post a hint and still let the user reset the behaviour)