I’m new to KDE and I have some mismatched expectations with window activation and focus:
If I click on a Thunderbird notification for a new email, I expect TB to bring itself to the foreground and show the email. Instead, clicking on the notification does not bring up the TB window—all it does is add a very discreet orange background to the taskbar icon with no other indication that anything’s happened.
In Konsole, if I run /opt/sublime_text/sublime_text README.md to open a file in Sublime Text, I expect ST to bring itself to the foreground and show the file. If ST is not already open, it will do what I expect. If ST is already open, it does not bring up the ST window—all it does is add a very discreet orange background to the taskbar icon with no other indication that anything’s happened.
In both scenarios I want the app to raise itself to the foreground and take focus. Is there a way to allow certain apps to take focus when activated, either thru following a notification popup or from executing a shell command?
BTW, the apps I give in the above examples are not the only apps that do this: it happens with pretty much all apps I use while running KDE. GNOME started doing this annoying behavior several releases ago, instead showing a notification saying “Application SuchAndSuch is ready”, but I used an extension called “noannoyance” to get around it for certain apps. I’m hoping there’s a built-in way to fix this problem in KDE.
const WHITELIST = [
'org.kde.konsole',
'org.mozilla.firefox',
'sublime_merge',
'sublime_text',
'tilix',
]
function main() {
console.info('[focuser] INSTALLING')
// Existing windows
workspace.windowList().forEach(configure)
// New windows
workspace.windowAdded.connect(configure)
console.info('[focuser] INSTALLED')
}
function configure(window) {
if (!isAllowed(window)) {
console.info('[focuser] SKIP DISALLOWED', window.resourceClass)
return
}
console.info('[focuser] CONFIGURE', window.resourceClass)
window.demandsAttentionChanged.connect(() => grantAttention(window))
}
function grantAttention(window) {
console.info('[focuser] GRANT', window.resourceClass)
workspace.activeWindow = window
}
function isAllowed(window) {
return WHITELIST.includes(window.resourceClass)
}
main()
While writing this plugin, I noticed this in the console output:
kwin_core: Cannot grant a token to KWin::ClientConnection(0x559bb8c3f9a0)
kwin_core: Refusing to activate KWin::XdgToplevelWindow(0x559bc0ed9cf0, surface=KWin::SurfaceInterface(0x559bbb7ca2a0), caption="~/src/dotfiles - Sublime Merge") (provided token: "not-granted-666" , current token: "null" )
This seems like a bug to me but not a single comment here or any mention of this kind of thing online. Is completely destroying the usefulness of window activity some Wayland initiative because Gnome did the same user-hostile thing years ago with the constant “SomeApp is ready” notification popup instead of giving SOME way to actually auto-activate the thing for certain applications (again, this nonsense is what noannoyance was written to undo). How do people live like this with notifications that just don’t activate when clicked or windows that don’t pop open when you expect them to? This “fix” was certainly not an easy-to-find information for and it’s almost certainly too naive (I wrote it in about 15 minutes and I do not know this API) because I didn’t even know where to start.
Hi - it’s awesome and commendable resourcefulness to take advantage of free software and figure out a way to work around something that’s bugging you and hasn’t already happened in the core code base.
And just double-checking, it sounds like what you’re wanting is essentially the “None” setting for “Focus stealing prevention”, located in System Settings > Window Management > Window Behavior > Focus tab. It might be worth double-checking that setting’s value too.
Howdy. It’s not just notifications, though that one is the most egregious (it’s active input that gets dropped).
I did try every possible combination of “Focus stealing prevention”—on the global level, trying to set the most permissive settings on a per-window and per-application basis and none of it worked and based on it not seeming to have any observable effect whatsoever, it’s not clear what it’s even supposed to do despite every bit of info online saying that’s the answer to this problem. I saw this behavior across the KDE Plasma environments in Fedora 41, Debian 12 and 13.
Yes, by both the source and the target app actually supporting activation. Please make a bug report to the app you’re clicking the link in, if the app that should be raised ends up being marked in the panel, and the app that should be raised if it doesn’t.
Looks like you’re right, I found this bug on ST’s issue tracker: [linux/wayland] Opening file in Sublime doesn’t activate/focus existing Sublime window #6236 (https://github.com/sublimehq/sublime_text/issues/6236)
Doing a bit more digging, it looks like KDE/KWin has a 4 year old bug on activation from konsole to kate of status CONFIRMED that went radio silent two-ish years ago (https://bugs.kde.org/show_bug.cgi?id=442265).
I get the feeling this whole activation thing is still rough around the edges, application devs aren’t really interested in playing catch-up and there doesn’t seem to be an appetite for maintainers of the big DEs hearing about things that aren’t working, hence the proliferation of these little hacky workarounds for problems. I suppose living on a wing and a prayer that these workarounds don’t get closed out by future KDE/Wayland updates is the only option then.
For the record, I do appreciate what you guys do and other than this particular impossible-to-ignore problem, everything else is glorious. I just wish folks would say “yep, craps broke right now and we’re hoping someone submits a patch to fix it soon but it ain’t happened yet” instead of staying silent until someone says something provocative so people don’t spin their wheels scouring the web for TheRightAnswer™ that doesn’t exist.
That specific case is unfortunately expected to be broken, so far noone has seriously tried to fix it, as it’s somewhat complicated… to pass focus to another app, you need to have a window, and shells are mostly separate from the terminal emulator that’s running them.
Where are you getting that impression from? The bug report you linked is made by a KDE dev, and has comments from two other KDE devs in it explaining why it happens, what could possibly be done to fix it, and how all ways to go about it suck.
We have no intentions of getting rid of KWin scripts for the foreseeable future. They’re one of the things that make KWin so great for power users.
Maybe I’m just reading too much into the silence over here and it’s blending into memories of unpleasant experiences on the GNOME side. I’ve seen new feature and feature “re-add” requests with surprisingly unfriendly back-and-forth between maintainer and submitter over the years. I’m no shrinking violet but I think bikeshedding and getting emotionally worked up about tech stuff is kind of ridiculous. I’ve taken to just seeking out workarounds and extensions to fix broken things myself rather than have to go pick a fight with someone from whose free time I’m essentially demanding a big chunk of. What compounds that problem is that for almost every point release over there, the extension API seems to get mutated in a way that breaks extensions so it’s constant cat and mouse with a growing number of workaround extensions to restore basic things that were removed and that’s where the paranoia comes from.
I still don’t understand how “Focus Stealing Prevention” is supposed to work and I’m not certain it’s providing what a reasonable interpretation of its name promises. The insistence of this being The Answer despite it not doing what it seems to promise also contributed to my impression of “no appetite to hear about things that aren’t working”. If that’s not correct, I apologize.
Anyway, again, I do appreciate what you guys do. I’m very particular about my work environments and this is literally the only thing I was having a problem with and I was able to sort of fix it in 4 lines of code and it was significantly easier to test than its GNOME counterpart.
While it’s similar with KWin’s C++ plugins, our Javascript API is very stable and only gets changed very rarely.
X11 apps can and do focus any window whenever they feel like it. Some apps go as far as focusing their window multiple times right after startup, making them incredibly annoying to use. The setting configures how strictly KWin tries to prevent apps from doing this, but what the options do exactly is something I don’t know either… I’d be surprised if even a fraction of a percent of our users knew, or if any dev could list them all up. It’s a complicated mess.
What we’re doing with Wayland is a new system, where apps can only focus windows by transferring activation from the active window - so there simply is no “focus stealing” to prevent, but apps have to implement support for the new system or it just doesn’t work.
It’s also annoying, until all apps properly support it, but there’s at least a light at the end of the tunnel and most popular apps are already doing it right. Hopefully we can get rid of the “Focus Stealing Prevention” option in a few years, when app support is more complete.
