1

There're quite some issues with current focus stealing prevention.
It's nice to protect the window focus, but either you choose a weak setting (and get focus passed over even if you just don't type "fast enough") or -even for low stealing prevention- will possibly miss clients popping up behind the current window.

What worries me right now is that the user is supposed to select the least failing FSP from an unexplained (and likely unexplainable) list - i'd prefer sth. that works and have the custom strategies as fixing rule only - The NETWM compliant FSP is btw. "none".


The demands to focus management:
------------------------------------------------------------------------------------
- it should keep the focus at windows you operate on and not allow random clients to pop up for whatever reason and steal away the focus
- it should automatically pass the focus to wanted clients
- it should NOT stash new clients
- it should however also prevent accidental activation

Pitfalls:
------------
- processes can open clients anytime and request focus for existing clients anytime
- user interaction usually impacts the stating order ("clickraise")
- user interaction is not predictable (when & where will the next click happen)
- know whether a client is "wanted" or not

Proposals:
----------------
- for "smart" placement avoid the position under the mouse
- just raise the new window
- ensure visibility:
* set it keep above for about "some" time (eg. 250ms) to prevent it from being stacked under the current client with an "unrelated" click, then select the correct state (ie. dep. on rules)
* move the client to some least intersecting position with the active window (fails with eg. dialogs which need to be on their parent or are in doubt placed centered)
- for not smart placement (eg. dialogs) or if the position under the mouse cannot be avoided (did i comment on maximizing windows?) block all mouse input for "some" time (eg. 250ms) to prevent accidental activation or -worse- even interaction (activate*pass)
- after the timeout, restack the window below the active one (if it was temp. set to be kept above) on any interaction (when updating the timestamp of the active one) on the active one
- use a pretty strong focus protection, ie. raise the required timeout unless the client belongs to the same group or the active client is sth. like krunner


Improvements:
------------------------
- The client may be falsely denied to get the focus, but won't be stashed, so it only takes another click (or move the pointer there
- Hiding the new client becomes implicit and easy (just keep operating on the current window)
- We can be stricter on fsp, "protecting" input dialogs (but keep in mind that this is NOT A WAY TO SECURE INPUT like pinentry-* etc.)

Issues:
-----------
- detect krunner (add "applauncher" role? - docks should not be a problem because they don't take focus and it will take quite some time to get there and click an icon after stopping to interact with the current client)
- two maximized *sigh* clients (new one would temp. raise on top of the active one, completely occluding it - how would the user react?)
* can we use translucency here?