Re: Focus stealing

[Michael T <raselmsh hotmail com>]

Dana Jansens <danakj <at> orodu.net> writes:
> It's possible for a shell to use the startup notification protocol
> when running things, but it can get quite shadey when you are running
> things which will run others things (like other terminals), since the
> startup notification stuff is passed along in the environment.  It's
> not backwards compatible with older applications at all.
The X Terminal application could monitor the list of below it in the process
hierarchy and allow windows created by those pids to steal its focus.  But that
is relying on the window popping up to provide you with that information.  One
could also indicate whether one was willing to give unidentified windows the
benefit of the doubt of course.  That would be useful for applications like X
Terminals that don't know in advance what they may spawn.

> The real problem is that the WM does not have any control over focus.
> It can move it, but it can't prevent other applications from moving it
> too.  Really it can just watch and react to where the focus is, being
> unable to predict at all.  Fixing that requires a focus redirect,
> similar to substructure redirect, which would be an extension of the X
> protocol and server.
Of course, I realise that focus stealing prevention is currently a very
voluntary thing, requiring co-operative applications.

> Your suggestion of a "focus can get stolen now" indicator leaves a lot
> of openings for misbehaviour/races.  Focus can be stolen by whom?
Providing a pid, or a list of pids for example?  I know, that can get ugly. 
(The information should normally be available though, usually the application
launched will be on the same system as the launching application).

> [...] I would prefer a hint on new
> windows mapping such as _NET_WM_FOCUS_FROM, with a window ID, and if
> window with that ID currently has focus, then the new window takes it.
That sounds reasonable.

>  However, there is nothing stopping application writers from just
> sticking the ID of the current window in that property and always
> taking focus.  Many GTK+ applications already call _NET_ACTIVE_WINDOW
> on themselves after mapping, causing the WM to give them focus and
> take it away from other windows, for absolutely no reason, regardless
> of focus settings for "new windows" in the Window Manager.
Agree, this is a voluntary agreement between all parties.