Version: (using KDE 4.3.4) Installed from: openSUSE RPMs When opening an external konsole window via Shift-F4 the new window is forced to loose focus and the focus is returned to the dolphin window. If the desktop is hidden by other windows there is a good chance that the konsole window will be invisible (hidden by other windows). This is most likely excactly not what the user wants, the idea of opening a konsole window per keyboard shortcut is to have a shell and type the command(s) right ahead without having to search for the window.
The focus does go to konsole on my end. I'm running trunk, subversion revision 1103862, which says: dolphin 1.4 kde 4.4.67 (kde 4.4.67 (kde 4.5 >= 202100310))
Which window focus policy is used? I am using "Focus follows mouse" and the Konsole windows still open in the background, without focus (KDE 4.4.1 / Dolphin 1.4)
@Jo: The issue is independent from the focus policy I think. I can reproduce the issue in KDE 4.4.1, but not in trunk anymore (like Glen). No fix in Dolphin had been done, so I guess that a change in kdelibs after 4.4 solved this (I don't know if the fix got backported to 4.4.x).
The problem still persists with KDE 4.5.2 If it is not the focus policy, what's responsible then? Windows decoration, KDE theme, color sheme, ...?
The problem still exists with KDE 4.5.3 However, it does not seem to relate to dolphin as the same occurs with konqueror in "File Management" mode. Maybe kwin, but I don't know. I try to pile up my window related settings and hope someone can reproduce: Window manager: kwin 4.5.3 Widget Style: Plastique Window decorations: Plastik Desktop Theme: Air
I think this problem is solved in 4.7.0
Nope, problem still exists with KDE 4.7.0
I think the problem depends upon whether some konsole process is already running. The sure way of NOT reproducing it: 1). make sure no konsole is running(run 'ps aux| grep konsole' in another terminal emulator to confirm it). 2). open dolphin, and use Shift+F4 to open konsole. 3). that konsole window gets focus The sure way of reproducing it: 1). make sure no konsole is running(run 'ps aux| grep konsole' in another terminal emulator to confirm it). 2). use Alt+F2 to open konsole from krunner(IMPORTANT) 2). open dolphin, and use Shift+F4 to open konsole. 3). that konsole window does NOT get focus Another sure way of NOT reproducing it: 1). make sure no konsole is running(run 'ps aux| grep konsole' in another terminal emulator to confirm it). 2). start konsole from another terminal emulator(xterm/gnome-terminal) 2). open dolphin, and use Shift+F4 to open konsole. 3). that konsole window gets focus So I think this is related with konsole trying to be a singleton process.
ACK. THX for bringing up another subject, I wouldn't have thought of konsole itself being the cause. > So I think this is related with konsole trying to be a singleton process. I don't see any point why a KDEish xterm should be a singelton, but I am not a KDE developer. However I doubt this is a "junior-job"
Bulletproof way to reproduce it: I have 6 virtual desktops and a konsole instance on #6. If I open a konsole by hitting f4 on another virtual desktop, it doesn't get focus.
*** Bug 186293 has been marked as a duplicate of this bug. ***
From comment 6 in bug 186293: this will not "fix" from kwin side the reason is the focus stealing policy: konqueror spawns the konsole window on keypress, the window gets a timestamp and than you release the key and konqueror gets an update to it's usertime ("last interaction") since konsole is in another process and there's no other hint that this "belongs" to konqueror (eg, group leader) this is by most focus stealing policies (except for "none" which is btw. the plain NETWM way, while "low" is kwin default) interpreted as "user interacts on konqueror, don't allow new client to steal the focus" The solution would be for konqueror to set a hint on the konsole window "this belongs to me" or simply spawn it on the key release instead of the press. -> re-assigning, sorry that it took so long :-( Changing KWin's focus stealing policy to "None" most definitely resolves this bug. But the curisous thing is that the focus stealing policy does not work as intended when no other konsole is already running.
(In reply to comment #12) > Changing KWin's focus stealing policy to "None" most definitely resolves this > bug. But the curisous thing is that the focus stealing policy does not work as > intended when no other konsole is already running. Need to look up the xprop's but most likely the brand new process as a subprocess of dolphin/konqueror will get the critical hints automagically from Qt/QProcess/QApplication (is the konsole started detached?)
is should no detach myself from bugs of groups i'm not subscribed to ...
Hi As this bug has not been fixed as of KDE 4.8.3 (I have checked openSUSE 12.2 beta1), I decide to share with simple workaround: just disable focus stealing prevention for konsole only. There are two ways to do it: 1. Open konsole, right click on title bar → Advanced → Special Application Settings → Appearance & Fixes tab → check Focus Stealing Prevention and set it to "None" 2. Go to System Settings → Window Behavior → Window Rules → click New → in "Window Class" check "Exact Match" and write "konsole" → in Appearance & Fixes tab → check Focus Stealing Prevention and set it to "None" Konsole windows opened from Dolphin will be focused. I don't think this workaround has any drawbacks (after all, if we open konsole window, then we want it to have focus, right?). May I suggest to provide that setting by default in kwin? If I am not mistaken, kwin already provides similar setting for xv.
Resetting assignee to default as per bug #305719
*** Bug 305839 has been marked as a duplicate of this bug. ***
KDE 4.10.5 is OK (Kubuntu 13.04), please, close this ticket.
(In reply to comment #18) > KDE 4.10.5 is OK (Kubuntu 13.04), please, close this ticket. No, the problem is not fixed yet . Read comment #8.
Yes, the problem is still there indeed. But is Dolphin really the right product for this report? To be honest, I don't have any good idea how this could be fixed on the Dolphin side (starting Konsole when releasing the keys would require some ugly hacks because QActions are triggered on key *press*). Could it be that it's Konsole's fault?
(In reply to comment #20) > Could it be that it's Konsole's fault? There's no "fault" - and certainly not the one of the subprocess. To kwin the scenario looks like konsole was trying to steal the focus from (foreign/unrelated) dolphin, what's therefore denied. Unless you have access to the spawned windows id (to set some relation hint, like altering the client leader or even make konsole a transient for dolphin - depending on what is intended) my only idea was to "fake" what the newly instanciated process probably "accidentally" does to workaround the problem: delay the call, ie bind the action to a slot ::deferSpawningKonsole() { m_konsoleSpawnTimer->start(300); // 400? 500? } This solves tow issues for one: 1. The user probably meanwhile released the key "for a while" when the konsole window finally appears, thus it should be granted the focus. 2. You won't run into "issues" caused by automatic key repetition (ie. keeping Shift+F4 pressed and spawn a hundred konsole windows) - if the delay is above the keyboards repeat rate.
(In reply to comment #21) > (In reply to comment #20) > > Could it be that it's Konsole's fault? > > There's no "fault" OK, but to the user, it looks like a bug. I run into this issue myself once in a while, and I find it quite annoying that I have to press Shift+F4 and then Alt+Tab to get a Konsole ;-) > ::deferSpawningKonsole() { > m_konsoleSpawnTimer->start(300); // 400? 500? > } Tried something like that, but it has no effect at all (except that it takes a while until the Konsole window is opened): http://paste.kde.org/pfb696234/ > This solves tow issues for one: > 1. The user probably meanwhile released the key "for a while" when the > konsole window finally appears, thus it should be granted the focus. No, it's not granted the focus. So it looks like it does not have anything to do with the "key press"/"key release" issue. Note that you can also open a Konsole by clicking "Open Terminal" in the "Tools" menu. The action is definitely invoked on mouse button *release* then, but the new window is still opened in the background. BTW, I tried running a few more apps from Dolphin, like * Kompare (select two files and then either open it from the "Tools" menu or assign a keyboard shortcut to that action) -> the Kompare window appears in the foreground. * Kate: make sure that Kate is running, and open a text file in Kate -> the Kate window is focused and appears in the foreground. Moreover, as has been noted here before, it works fine with Konsole if no other Konsole window is open yet. Considering all these things, I wonder if Konsole might be doing anything weird. But I'm not sure - some more debugging might be required to find out what is going wrong and if/how it can be fixed. In any case, from the point of view of Dolphin (which this report is assigned to), this is "WONTFIX", or rather "CANNOTFIX" as far as I can say :-(
Removing 'junior-job' keyword - this is definitely not a job for beginners.
(In reply to comment #22) > Considering all these things, I wonder if Konsole might be doing anything > weird. Yesno. The new window clones the usertime of the present konsole window (none if the other konsole window had not been touched so far) what is usually far back compared to the usertime of dolphin ("just") The assumption here is: some client spawns a dialog out of the void (no interaction with that client caused this) For "regular" application calls, they've either no timestamp at all (if it's the first window of the application, _KDE_NET_WM_USER_CREATION_TIME is used instead) or just set "currentTime" to raise odds to get the focus. --> What needs to happen is that if konsole main() spawns a new window instead a new process (and only in this case) it either has to "unlink" the windows (different pid or class - what's of course less great either) or sets the usertime to what what usually would become (and actually does) _KDE_NET_WM_USER_CREATION_TIME, faking that activity in the present client caused the new window. This might be an issue for similar acting clients (including dolphin ;-), though.
I'll reassign this to Konsole - I cannot see how this could be fixed inside Dolphin.
After upgrading from Konsole 14.12 to 15.08, the shortcut to open the konsole caused Konsole to be opened in the background. With the focus policy set to None (as explained at https://bugs.kde.org/show_bug.cgi?id=221107#c15), the konsole is now focused as expected.
(In reply to Rob from comment #26) > After upgrading from Konsole 14.12 to 15.08, the shortcut to open the > konsole caused Konsole to be opened in the background. > > With the focus policy set to None (as explained at > https://bugs.kde.org/show_bug.cgi?id=221107#c15), the konsole is now focused > as expected. This works for me too, thanks
This works for me as well for 15.08. But to clarify, make the change in: System Settings > Window Management > Window Rules. Don't worry about the "right click the title bar" bit.
This manual adjustment of window rules can only be reagarded as a temporary solution to the problem. The "Open Terminal" function should work as intended from the start. Let me restate the problem, as it still appeares in Plasma 5.6: 1) Open Konsole 2) Shift focus to Dolphin 3) Press in Dolphin "Open Terminal" in Toolbar or hit Shift+F4 4) New Konsole window stays in background (with multiple windows open: directly one layer under Dolphin) It's not happening when: * Skipping Step (2) above * In (3) "Open Terminal here" via Dolphin context menu -> Actions * Setting focus policy to None as explained above Cause: KWin focus stealing prevention, because Konsole uses same process for new windows Possible fixes (probably not the best of the best): * Use same method to open new window as in the context menu action * Use one process per window in Konsole (as Dolphin does for example)
The situation has changed, now by default konsole runs each window as a separate process and IIRC the konsole lead developer is planning to drop the option to run all konsole windows in a single process altogether; the problem seems to be fixed. Closing as worksforme.