(I doubt this is actually khotkeys fault - but I'm not sure which components fault it is) I use the Example hotkeys example of ctrl-alt-t to 'Run Konsole' and I've used it for years on KDE4, but I'm finding on KDE5 the konsole often doesn't open on top (if at all?) Reproducible: Sometimes Steps to Reproduce: 1. Enable the Custom shortcut example 'Run Konsole' 2. Open a full screen window 3. hit ctrl-alt-t (or whatever binding you had) Actual Results: Apparently nothing happens, but you often find the konsole has started but is buried a few layers down Expected Results: Konsole on top. Fedora 22 khotkeys-5.2.2-1.fc22.x86_64
That's either a bug in Qt/KMainWindow/Konsole or a bug/misconfiguration in KWin. Does the konsole window get the input focus? Does the fullscreen window still have the focus? Where is the focus (ie. what window receives keyboard input)? What's the configured level of "focus stealing prevention" in "kcmshell5 kwinoptions"?
(In reply to Thomas Lübking from comment #1) > That's either a bug in Qt/KMainWindow/Konsole or a bug/misconfiguration in > KWin. > (Confirming this on kubuntu, since my F23 box is now not KDE) > Does the konsole window get the input focus? No > Does the fullscreen window still have the focus? Yes > Where is the focus (ie. what window receives keyboard input)? The fullscreen window (or just the previous window, even if it wasn't full screen) > What's the configured level of "focus stealing prevention" in "kcmshell5 > kwinoptions"? Policy: Focus follows mouse- Mouse precedence, Delay focus by 300ms Focus stealing prevention: Low Click raises active window: Off Raise on hover: Off This is Ubuntu wily; khotkeys 4:5.4.2-0ubuntu1; this is also my older hardware (Core2, spinning rust) while I originally reported it on a reasonably fast i7 with ssd; so it doesn't sound like it's system speed dependent; and since it's on both Kubuntu and Fedora it doesn't sound like a distro bug.
Does it matter - what the fullscreen window is (read: that it is a Qt5 client window)? - that it's fullscreen? - what the khotkeys shortcut is (notably whether it includes ctrl and/or alt)? - that the focus stealing is not "none"? It's presently not reproducible but I noticed that on pressing/releasing ctrl+alt+t Qt5 windows briefly loose and regain focus just before konsole shows up. This could easily bump their user time ahead of the konsole start time and vanilla* kwin will deny konsole the focus. * https://git.reviewboard.kde.org/r/124130/
(In reply to Thomas Lübking from comment #3) > Does it matter > - what the fullscreen window is (read: that it is a Qt5 client window)? Not apparently; I've used firefox, libreoffice writer, and kate. > - that it's fullscreen? No, for example a firefox or pidgin partially covering the screen the konsole is appearing behind the existing window. > - what the khotkeys shortcut is (notably whether it includes ctrl and/or > alt)? OK, that's an interesting observation; I bound it to ` and it was correct at the front. I bound it to Alt+T and it was at the back. I bound it to ctrl+0 and it was at the back. I bound it to ctrl+` and it was at the back. which is odd, since it suggests it's neither the ctrl, the alt, or the ctrl+alt specifically but any of them. > - that the focus stealing is not "none"? It works correctly, i.e. at the front. > It's presently not reproducible but I noticed that on pressing/releasing > ctrl+alt+t Qt5 windows briefly loose and regain focus just before konsole > shows up. > This could easily bump their user time ahead of the konsole start time and > vanilla* kwin will deny konsole the focus. > > * https://git.reviewboard.kde.org/r/124130/
Ok, bottom line is that FSP hits; it seems because of the modifier, which is kinda weird. The shortcut should fire on keypress events, so both releases occur afterwards. The relevant change might have been the switch to xcb in kglobalaccel or kwin. @Martin time to revive https://git.reviewboard.kde.org/r/104317/ ?
I'm seeing this on KDE 5.7.5 (Ubuntu 16.10 yakkety) and 5.8.5 (from the Kubuntu backports PPA).
This issue report is quite old. Can you please confirm, that it still persists with KDE 5.23?
I haven't seen this in a long time; not reproducible with Plasma 5.22.5.
User reports issue doesn't happen in KDE 5.22.5