Re: How should the ICCCM's InputHint and WM_TAKE_FOCUS interact with the EWMH's _NET_WM_TYPE and _NET_ACTIVE_WINDOW?

[Lubos Lunak <l lunak suse cz>]

On Thursday 01 of March 2007, Havoc Pennington wrote:
> Dana Jansens wrote:
> > To implement this behavior via the ICCCM standards, you would make the
> > gnome-panel follow the "Globally Active" focus model. It's InputHint
> > would be set to false, telling Metacity to not give it focus, but it
> > would have WM_TAKE_FOCUS, stating that it may take focus on its own in
> > the future. Then, when a button is pressed on the text field of the
> > panel, it would simply call XSetInputFocus on itself, allowing the
> > panel to acquire focus.
>
> Here is some metacity history:
> http://bugzilla.gnome.org/show_bug.cgi?id=160470
>
> And links to this wm-spec-list thread:
> http://mail.gnome.org/archives/wm-spec-list/2004-October/msg00005.html
>
> I'm quite sure we considered the solution with the globally active
> model, but I don't know why it wasn't used. One problem may have been
> that the panel applets are not the same X client as the panel itself, or
> it may just be that gtk and/or qt make it hard to do it with
> WM_TAKE_FOCUS, or there may have been fundamental reasons.

 IIRC globally active model really complicates or even breaks focus handling 
in more complicated scenarios (e.g. focus stealing prevention), but that's a 
really vague feeling and I may be wrong here. I don't feel very urged to 
analyse this in detail just in order to replace something that apparently 
works with something else that possibly might work as well.

> > It seems that the _NET_WM_TYPE field has now superceded the InputHint,
> > but without any suggested symantics for it given in the specification.

 It has not superseded it, it's just that TYPE allows the WM to override many 
things on a more general base. TYPE_DOCK also usually means that it's not 
movable/resizeable, so it can override geometry hints, and so on.

> > When a window sets its window type, which window
> > types should it not expect to be given focus without requesting it?
> > Which should it?

 The one where the WM does/doesn't find it logical to do so (standard WM 
answer #184).

> > None of these interactions between the ICCCM and EWMH are currently
> > addressed, leaving them to be implemented in a somewhat random fashion
> > from application to application and wm to wm.
>
> Well, to be fair, any app that that isn't totally old and crufty, or
> written by someone with a great love of goofing around with Xlib, will
> be using a toolkit; and the toolkits pretty much sort this out for you.
>
> Assuming kwin is still working the same way as mentioned in the old
> wm-spec-list thread though, I think the main thing to add to the spec is
> that DOCK is expected NOT to be focused on click, and has to
> _NET_ACTIVE_WINDOW itself when an entry box needs to be interacted with.

 I guess such a recommendation could be added if somebody needs it.

> I don't think InputHint is modified by EMWH since it's an orthogonal
> issue of how to focus, it does not control when to focus.

-- 
Lubos Lunak
KDE developer
--------------------------------------------------------------
SUSE LINUX, s.r.o.   e-mail: l lunak suse cz , l lunak kde org
Lihovarska 1060/12   tel: +420 284 028 972
190 00 Prague 9      fax: +420 284 028 951
Czech Republic       http//www.suse.cz