Version: (using KDE Devel) Installed from: Compiled sources this is meant as sort of an even more extreme focus stealing prevention. my use case: i often start xmms and "xterm -e mc" almost simultaneously - using the commander for filling xmms' playlist. i.e., i don't ever want xmms to get focus when it starts up, but i also don't want to prevent it from receiving focus at all.
This feels way too specific. Doesn't focus stealing prevention already handle putting xmms in background because of the user action launching "xterm -e mc" ?
not if i do it the wrong way round ... or if the xterm is already open and i want the xmms launched "into the background".
a) are you still using xmms? ;-) b) the extreme focus stealing prevention should do that - the focus is not passed w/o user interaction - or is there something i miss (like xmms fetched the focus through the pager/tool request, where it's just granted)?
it's called audacious nowadays, but yes, i use it. ;) the extreme focus stealing prevention apparently does what i want. of course this state will persist beyond the initial mapping of the window, but presumably no later focus stealing is reasonably possible anyway.
thanks for the reaction ;-) explicit activation by mouse or alt + tab is not covered by FSP, nor are "tools" as pagers or taskbars (or actually anything claiming to be one) the only "reasonable" focus request from the client after initial mapping is to manage activation areas, ie. deny to take focus from the WM, check the position of the mouseclick and decide whether to take focus itself. (xmms might have done this, no idea) in that case the client should however consider to invoke the tool hint.