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: [EMAIL PROTECTED] , [EMAIL PROTECTED] Lihovarska 1060/12 tel: +420 284 028 972 190 00 Prague 9 fax: +420 284 028 951 Czech Republic http//www.suse.cz _______________________________________________ wm-spec-list mailing list wm-spec-list@gnome.org http://mail.gnome.org/mailman/listinfo/wm-spec-list