Summary: | Medium focus stealing prevention should also prevent focus stealing when the timestamp on the active window is uncertain | ||
---|---|---|---|
Product: | [Plasma] kwin | Reporter: | rlk |
Component: | core | Assignee: | KWin default assignee <kwin-bugs-null> |
Status: | RESOLVED DUPLICATE | ||
Severity: | wishlist | ||
Priority: | NOR | ||
Version: | 4.9.0 | ||
Target Milestone: | 4.11 | ||
Platform: | openSUSE | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | ||
Attachments: | Requested debug output |
Description
rlk
2012-08-07 18:04:02 UTC
It's not a matter of toolkit but of timestamps. Therefore also your description is wrong: (at least here) xterm does not update timestamps on interaction (for what reason ever) but konosle does. As a result while typing in konsole no window will (easily, it's still possible to actually steal focus but eg. kwrite don't) steal the focus but when doing the same from xterm, every (including each gtk+ app i tried) will. No idea about the documentation, but the definition in the code is clear: // 2 - normal - focus stealing prevention is applied normally, when unsure, activation is not allowed A possible improvement could be to also check whether the timestamp of the active window is undefined but the general behavior is as intended and for sure depends on your interaction with the currently active window. The behavior is the same for konsole and for xterm. If I type kmines or konqueror in either, when kmines or konqueror pop up they steal focus away from the konsole or xterm. If I run gimp or xterm from the terminal command line, they don't. From a user perspective, it looks like focus has been stolen from the active window. There must be sth. else then. Please run kdebugdialog and activate "(1212) KWin", then restart kwin from konsole: kwin --replace > kwin.debug 2>&1 & cause the focus stealing and attach kwin.debug (you can then disable the debug out again) Created attachment 73038 [details]
Requested debug output
This time, starting emacs or gimp from either xterm or konsole made no difference -- focus jumped to the new window both times. Evidently I don't understand focus stealing. I assumed focus stealing means that a window is prevented from grabbing focus; whether it's new or existing doesn't matter. Is that assumption incorrect? There's no debug output in the attachment - did you "apply" kdebugdialog before restarting kwin? > This time, starting emacs or gimp from either xterm or konsole made no difference -- focus jumped to the new window both times. As mentioned, it's about "activity" (eg. any keystroke) in the active window _only_ > I assumed focus stealing means that a window is prevented from grabbing focus; whether it's new or existing doesn't matter. That does only hold for "extreme" fsp The NETWM standard is "none" ie. when a window opens it will just get the focus, but that's aannoying so fsp was introduced quite early. There's no real definition for its behavior and what it does is basically to check whether the window that wants the focus is related to the active on and whether there's currently interaction with the current window and based on that decide what to do. The problem is that the outcome is too aggressive for some users and to weak for others and -worse- that many windows cannot reasonably state a relation (or are just broken) and are thus not passed the focus while they actually should. Therefore the brainstorm proposal... The RR on the dupe actually has this behavior (among other changes) *** This bug has been marked as a duplicate of bug 110543 *** |