When using KDE Plasma and KWin as a window manager, focus stealing prevention level is on low (or medium, I can't remember) by default. This setting prevents Okular from focusing Kate when shift-clicking somewhere in a document using synctex if Kate is already open and not minimized. STEPS TO REPRODUCE 1. Open a PDF document compiled with synctex support (e.g. pdflatex --pdflatex -synctex=1 document.tex) 2. shift-click on a word. Kate is open and focused with the source document, at the right position. 3. Don't minimize Kate. Switch back to Okular. For instance, using Alt+Tab (common workflow) 4. Redo this again. OBSERVED RESULT Notice that Kate blinks in the task bar, but is not focused and remains in the background. EXPECTED RESULT Kate should be focused and put at the foreground, even if it was not minimized before. SOFTWARE/OS VERSIONS Linux/KDE Plasma: Yes, X11 KDE Plasma Version: 5.15.4 KDE Frameworks Version: 5.57.0 Qt Version: 5.12.3 ADDITIONAL INFORMATION The behavior is correct when disabling focus stealing prevention, or when using xfwm4 instead of KWin. P.S. Maybe related to the following bug? https://bugs.kde.org/show_bug.cgi?id=404643
> Notice that Kate blinks in the task bar, but is not focused and remains in > the background. KWin marked the client as demanding attention, so this is expected behavior. > This setting prevents Okular from focusing Kate when shift-clicking > somewhere in a document using synctex if Kate is already open and not > minimized. I'm pretty sure that time stamps are off, which means this bug should be fixed on the client side.
I'd say this is probably a kate bug? I've been having the same problem when invoking kate from the command line recently, it doesn't popup itself sometimes. I tried finding the alias to include the kwrite mailing list here but failed, so included a few random people hoping they will comment.
I have noticed the same behavior when calling Kate from Konsole since reporting this bug. Should we change the product to Kate?
Moreover, calling Firefox about:blank from Konsole does bring Firefox on the foreground in any case.
The first what popped in my mind was a note on some of my own project: // FIXME When the window is behind some other window it comes // not in front. Using raise() has no effect on my KDE. // Calling hide();show(); has, but flicker unpleasant activateWindow(); Related Kate code is there: kate/kateapp.cpp-493- win->activateWindow(); kate/kateapp.cpp:492: win->raise(); kate/kateappadaptor.cpp-44- win->activateWindow(); kate/kateappadaptor.cpp:43: win->raise(); kate/qtsingleapp../qtsingleapp..cpp-185- actWin->activateWindow(); kate/qtsingleapp../qtsingleapp..cpp:184: actWin->raise(); And a new Kate bug on MS Windows which may also related: Bug 407288 - Kate doesn't bring existing session into foreground
Are you using Kate with a saved session, out of curiosity? If so, it's the same issue as Bug 407288.
@Nate: not me.
@Nate: In the bug you mentioned, the reported does not speak about saved sessions. In my understanding, it might actually be the same bug.
question was answered
Yep, looks like the same bug. *** This bug has been marked as a duplicate of bug 407288 ***