Version: (using KDE KDE 3.5.4) Installed from: Compiled From Sources Compiler: doesnt apply doesnt apply OS: Linux Greetings, I've got a dualhead X11, screen0 and screen1, NO xinerama. They are two screens, screen0 below screen1, I can move mouse from one screen to the other but not the windows. When i open a windows it stay on that one. Bug #1: Often when closing or opening windows, the wm has to select another window for focus. It happens that a window on the other screen is selected. This is very annoying as focus should NEVER jump from one screen to the other, as windows starts to open in the other screen and alt+tab allows only to change between the windows of that screen. Bug #2: When using kate (but i strongly suspect it is NOT kate related), I hit ctrl+f and search for a string. After doing next a few times, i get the usual message "No more occurrences found". After confirming that dialog, the focus jumps to the first window of the other screen! It is isntead supposed to return to the modal-dialog-owner window. I can compile svn 3.5 branch if you manage to fix the bug to verify it. This bug has always been there in 3.5.x previous releases. Thank you for your help.
I'm afraid non-xinerama multihead support is unmaintained in practice.
this is horrible! i cannot believe this. I need to hear this from Stephan Kulow's keyboard :-) no really..it works pretty good, there is just this focus bug, i guess it's not that hard to fix for those that are involved in the relevant code.
I can confirm this on KDE 3.5.7. If I hit ctrl+d in konqueror, make a folder, and then hit cancel, the other desktop is [most of the time] highlighted, instead of focusing back to konqueror which would be the expected behaviour.
I can confirm again on KDE 3.5.8. The focus bug happens even more often! I think you are not going to fix it, are you? Please at least for KDE 4!
Same here Johnny - the focus almost flipflops every other focuschange. But if the fix requres stringchanges I doubt it will get any attention for the 3.5 branch anyway. Luckily at least there's this http://users.tkk.fi/~spniskan/switchscreen/ so I don't have to keep reaching for the mouse.. However it is still quite annoying.
*** This bug has been confirmed by popular vote. ***
This is indeed super annoying. I too have the multiscreen X configuration and like to play DVDs, etc, on the second screen while working on the first. Periodically, focus mystically jumps to the second screen during desktop switches, often resulting in me stopping vlc to the great annoyance of those watching the DVD. I suspect this is related to the fact that there's a kwin process for each screen; I believe there may be race condition between them. For now, just killing the kwin for the second screen works, but that's not much of a long term solution. I've noticed that setCurrentDesktop() starts getting called in the second kwin; is it possible to add a check at the top of this to check to see if the pointer is even on the current screen, and if it's not, to return immediately?
Same here, and it is indeed annoying. One observation: it is much worse if the screen have different number of desktops. It does happen even with same number of desktops in them, though. :-(
*** Bug 138149 has been marked as a duplicate of this bug. ***
I can confirm this bug on KDE 4.7.4 (Kubuntu 11.10) Actually for me the focus jumps between screens any time a window is closed. Very annoying I might add; I have to hold on to the mouse all the time.
I think this might be the same as bug 237260, especially as described in comment #10. I provided a more detailed description in the duplicate bug 274369, but the problems described here also seem to occur on my system, especially comment #3. Whenever I create or rename a folder (in dolphin, not konqueror though) the focus is moved to the second screen, though I don't need to cancel it for the problem to occur. Also, I'm running KDE 4.7.4, so the similarity might be purely coincidental.
This is bug #157219 which has more detail on the source of the issue. It is related to #237260 but alt+tab won't work when this bug here is fixed. *** This bug has been marked as a duplicate of bug 157219 ***