This will probably sound a bit far-fetched, but the more I think about it the more I think it'd be useful for users who like me prefer to do as much as possible with the keyboard: Many applications, among which web browsers, have a feature (sometimes optional) in which the running instance "activates" itself when it receives a document or page reference to open. Even if that's the desired behaviour in most cases, there are also circumstances where you don't want this to happen. Example: I'm scanning my email and/or RSS feeds in Kontakt, say for housing or job ad alerts. I'll be coming across a number of links I'll want to investigate, but I don't want to handle each link serially, going back and forth between apps. Currently, that means I click on a link, then have to move the mouse cursor outside my zone of (mental) focus in order to give the (input) focus back to Kontakt because my browser stole it when coming to the front. (Despite have focus-follows-mouse and the mouse cursor over the Kontakt window.) Let me repeat that often this is wanted behaviour: let a window activate and get focus without having to touch the mouse. I don't see many ways how you can alter this behaviour on a case-by-case basis, but a hotkey feature in the window manager should be a solution. Define a modifier or function key (or any key that usually does nothing useful) to be pressed when or immediately after you click a link or do something that'll cause the designated document handler to activate. When this hotkey is pressed, KWin will not allow focus to change. You might even make this a 2-level feature: optionally KWin could also "freeze" the window stacking order. (Useful on small screens, or if you set your browser to take up the entire screen so the focus window becomes hidden anyway.)
Please have a look at window rules for focus stealing prevention. There is not much more we can do. We don't know that you clicked a link. All we see is that there is a valid request from another application to gain focus. With focus stealing prevention you can disallow such requests. But a dynamic feature is not possible.
I already looked at those, they're set to what's most commonly useful. Similarly I have focus-follows-mouse set to the best compromise setting. I've also already asked around for other things that could improve the experience in the scenario I described ([1]) Maybe my description was too long to be readable. You can implement various levels of focus stealing prevention in KWin, right? Why then couldn't you implement a version where keeping a certain key pressed switches prevention to the strictest form? Technically speaking of course? I realise of course that you cannot know the context of a focus or raise request, but the user does and can do something to moderate the effect of the request he just triggered. 1) a WM command-cum-hotkey "give focus to the window currently under the mouse" would also do the trick for me. Hitting that key to restore focus is not very different from keeping a key pressed to prevent focus from changing. I could of course click the mouse button but that would always raise the window, which is not always what I want.
Please consider window specific focus stealing rules. What you want is a higher lever for the browser.
It's a start, not really ideal and I don't seem to have any documentation for it at all (thanks for pointing out that I need to protect the browser, the opposite of what I'd have expected). I'm obliged to use "high" protection to see any effect at all and that means browser windows not only NOT get focus when they ask for it, they're also not being raised. As I said, that's the higher level of the feature I hope for. Is there a way to override processing of all specific rules, either as a toggle with a hotkey or coupled directly to a hotkey? That would also work for me, I think, and might be a more generally useful feature to implement if it doesn't exist yet.
> Is there a way to override processing of all specific rules, either as a > toggle with a hotkey or coupled directly to a hotkey? No > That would also work > for me, I think, and might be a more generally useful feature to implement > if it doesn't exist yet. Almost impossible to implement. Thus won't happen.
Pity. If you don't mind my asking: So that means that there's no point to search through the code looking for some kind of central location where a decision could be made to ignore certain kinds of rules? Roughly speaking, does that mean that such a switch would have to be implemented in about as many locations as there are features in the window rule editor window (and that the central rule execution engine is unaware of the context)? Or maybe there isn't such a thing as a central rule execution engine or even a function to check whether there's a rule to execute? FWIW, have I been shooting my idea in the foot by talking about "specific rules"? This was the first time I ever really used one so I have no idea how much of KWin's standard functionality is implemented via rules one cannot disable without breaking things.
Rules are a million checks spread over the complete code base.
Hah, indeed. Comes as a bit of a surprise though I guess it helps explain why KWin is such a big chunk to build. If some reorganisation is possible that could be a "nice" junior job(? ... not just for my idea evidently!)
(In reply to RJVB from comment #8) > Hah, indeed. > > Comes as a bit of a surprise though I guess it helps explain why KWin is > such a big chunk to build. No, it's just that KWin is large. We are now at 155 kSloc - for comparison: plasma-workspace is "just" 88 kSloc > If some reorganisation is possible that could be > a "nice" junior job(? ... not just for my idea evidently!) No, not for the rules. It's just the way how that is implemented. Every place where a rule checked feature is used, the rules are verified. I don't see any possibility to change this. Especially not as a junior job.