Hi, To be clear up front, to get this fixed someone will probably need to write a patch to the docbook for the EWMH ;-)
Some comments on how I think things should work, though I have not thought it through comprehensively: Dana Jansens wrote: > Locally Active - The same as passive, but the application will also > give focus to other windows that it owns of its own free will, without > any interaction with the window manager, using XSetInputFocus. My view is that apps calling XSetInputFocus() on managed toplevel windows "out of the blue" is probably broken (since the WM has no chance to intercept). _NET_ACTIVE_WINDOW is probably almost always correct instead. For override redirect, or child windows (widgets), XSetInputFocus() is needed obviously. > Globally Active - The application will not receive focus from the > window manager. Instead it will determine when it wants focus (from > WM_TAKE_FOCUS suggestions given by the window manager, or from events > such as ButtonPress or KeyPress). The application will then acquire > focus on its own using XSetInputFocus. Apps that call XSetInputFocus() due to WM_TAKE_FOCUS is OK though, since here the WM had a chance to get involved. > 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. > It seems that the _NET_WM_TYPE field has now superceded the InputHint, > but without any suggested symantics for it given in the specification. metacity also supports all the InputHint stuff, as I'm sure kwin does. The DOCK type doesn't affect how focus is given once we decide to focus; the DOCK type just affects whether a mouse click tries to focus the window. In other words, there are two things: 1) when to focus - which is a WM policy, e.g. some WMs let you choose whether the first click focuses, etc. Also remember you can focus with keyboard not just mouse, e.g. in metacity ctrl+alt+tab is like alt+tab except for panels instead of regular windows 2) how to focus once we decided the user wanted to focus; this is done with InputHint. globally active windows can "veto" the focus at this point. I guess this points to one fundamental problem with trying to handle the panel via the globally active model, which is that the panel has no idea of the WM's focus policy - in terms of which buttons/keys should focus, or whether click to focus is even enabled. > What should a window manager do when InputHint is set to false, but a > _NET_ACTIVE_WINDOW is called on it, and it is a NORMAL or DIALOG or > ... _NET_WM_TYPE? _NET_ACTIVE_WINDOW does a bit more than just focus (it raises/"presents" the window), so my view is that the WM would always do those things, and then it would attempt to focus using the InputHint. If the InputHint doesn't allow focus, metacity will "fake focus" the window (it will look like the window is focused to the user, but really it isn't). If a globally active window does not focus itself, then the window would end up unfocused. metacity does this unconditionally without looking at _NET_WM_WINDOW_TYPE I believe. The window type is only used to decide *whether to attempt* to focus, and if we are going to attempt, the InputHint controls *how* we attempt. > 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 only thing I know of here is that DOCK type needs to activate itself if a text input control is selected. > How does each window type interract with the > InputHint? Generally there's no interaction; the window type only interacts with whether/when focus will be attempted, not with how focusing is done. > Should applications never be calling XSetInputFocus anymore? For managed windows as I mentioned above I'd say _NET_ACTIVE_WINDOW is preferred for saying "from a user perspective, the window should be activated" but XSetInputFocus() may be used as part of the actual implementation of activation, according to the InputHint rules. The implementation of activation may also include raising, switching workspaces, and stuff like that, in addition to focusing. > If so, what should window managers be expected to do when > WM_TAKE_FOCUS is present. Should this no longer be used to indicate > that a window is going to be calling XSetInputFocus sometimes (Locally > or Globally)? Is the WM_TAKE_FOCUS message expected to _at most_ make > the client send back a _NET_ACTIVE_WINDOW message? I don't think there's any InputHint relationship; e.g. afaik metacity 100% honors the InputHint. > If applications are never calling XSetInputFocus anymore, we are more > or less destroying the Locally and Globally Active focus models. Since > WM_TAKE_FOCUS is used to specify these models, is there any reason to > honor it at all in a modern desktop? Back compat if nothing else. But I believe GTK at least uses the two active models, I think they may be helpful in avoiding race conditions, others would know better. > 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 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. Havoc _______________________________________________ wm-spec-list mailing list wm-spec-list@gnome.org http://mail.gnome.org/mailman/listinfo/wm-spec-list
