| Summary: | Open new windows behind the dialog with input keyboard focus | ||
|---|---|---|---|
| Product: | [Plasma] kwin | Reporter: | Alexey Chernov <4ernov> |
| Component: | general | Assignee: | KWin default assignee <kwin-bugs-null> |
| Status: | RESOLVED DUPLICATE | ||
| Severity: | wishlist | ||
| Priority: | NOR | ||
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | Compiled Sources | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
|
Description
Alexey Chernov
2010-12-27 20:02:46 UTC
matter of focus stealing policy. "medium" should fit most clients, some try to self-rise/activate more "agressively" (so require "high" or maybe even "extreme") - you can use the rule system to raise the policy for them indepently. wally in particular could grab the mouse (with CARE!) thank you. and where can this be adjusted? there's a contextmenu entry to the individual window rules, but preferably run "kcmshell4 kwinrules" (for individual changes) the general focus policy is in "kcmshell4 kwinoptions", "focus" tab OK, but is it related only to focus or also affects window mapping order? I've posted just about mapping order, focus fortunately persists on dialog but it is hidden by other windows opened on top so I can enter something but can't see what I'm typing. No. In general any client can use XRaiseWindow to unconditionally raise anytime.
Afaics kwin atm. doesn't deny this request at all.
For the "autoraising" on showing up (MapRaised), this is not intercepted for "override" type windows (eg. popups are not dealt by the WM at all, but this atttribute can be applied to any kind of window. it won't get a decoration or focus/raise on click etc.), all others move through the focus chain and are only raised if this is connected to the focus ("click raises active window" or "raise with ... delay")
=> a nasty client could first to a MapRaised, enter the focus check, don't get the focus and is thus not raised, but then simply call XRaiseWindow and be raised nevertheless. This can considered to be a client bug (if there's no very strong reason for such behaviour)
Also some windows (docks, "keep above") will always reside on top of the "ordinary" windows.
What "window" are you talking about in particular? (because in genreal kde applications do afaics no such doubleraise)
Hmmm.. I see. The typical case is about KWallet dialog when it needs master password and KWrite. Every time on KDE startup KWallet dialog usually appears firstly. Then KDE starts to restore windows from previous session and it restores KWrite which in turn opens its window and overlaps with it KWallet dialog while I'm typing a password. The focus is still on dialog, everything's OK except I can't see what I'm typing anymore. Sometimes KWrite behaves itself more modest and map its window behind the dialog but I can't see what it depends on. Small thought is perhaps when I don't type a password until KWrite appears then it behaves normally but that's not obvious.. this is bug #167615 just checked and sth. seems broken about the timestamps, ie. the raise and/or activation is permitted because you don't seem to be active (but i typed nonsense as fast as i could) *** This bug has been marked as a duplicate of bug 167615 *** |