| Summary: | idea: "don't change focus" hotkey | ||
|---|---|---|---|
| Product: | [Plasma] kwin | Reporter: | RJVB <rjvbertin> |
| Component: | general | Assignee: | KWin default assignee <kwin-bugs-null> |
| Status: | RESOLVED WORKSFORME | ||
| Severity: | wishlist | ||
| Priority: | NOR | ||
| Version First Reported In: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | Compiled Sources | ||
| OS: | All | ||
| Latest Commit: | Version Fixed/Implemented In: | ||
| Sentry Crash Report: | |||
|
Description
RJVB
2017-11-17 09:54:21 UTC
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. |