On Wed, Aug 21, 2002 at 03:41:54PM -0400, Sergey Babkin wrote: > Dominik Vogt wrote:
[snip] > > The application is lieing about its focus model. It claims that it > > never sets the focus itself but still does so. This is a clear > > violation of the ICCCM rules. The window *must* set the > > WM_TAKES_FOCUS protocol in the WM_PROTOCOLS property and abide to > > it. If the problem persists once the application has been fixed, > > please report back. > > Well, the application never grabs the focus, it only moves the focus > between its subwindows after its main window gets focus. It *must not* no this without using the WM_TAKES_FOCUS protocol (see below). > Even though > ICCCM says that the applications with "Locally Active Input" should > specify WM_TAKE_FOCUS, it also says: > > The goal is to support window managers that want to assign > the input focus to a top-level window in such a way that > the top-level window either can assign it to one of its > subwindows ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Isn't that quite clear? > or can decline the offer of the focus. For > example, a clock or a text editor with no currently open > frames might not want to take focus even though the window > manager generally believes that clients should take the > input focus after being deiconified or raised. > > Declining the focus is not an issue with Tk. It also does not need the > window manager returning focus to the exact Tk's subwindow that had > the focus before it was switched out: once Tk's main window gets focus, > it can take care of passing it down by itself. > > Fixing all the copies of Tk out there is also not really an option. Anyway, we can't go about introducing bug after bug in fvwm just to cope with Tk which is totally broken in many aspects of window handling. Some bugs are knows for years and described pretty well and nothing was ever done in Tk about them. > In > this I would argue that the principle similar to IETF's "adhere to the > standards as closely as possible in your outputs but accept as wide variety > of inputs as possible" should apply to the window managers as well. And > seeing the focus change on mouse movement while I specifically selected > the focus mode that disables that looks wrong too. The standard is that the WM can do with the focus whatever it likes if the application fails to use the WM_TAKES_FOCUS protocol. > Basically, what I would like to know is whether this happened occasionally > or was done by design ? If it was done occasionally, I may be able > to find out the reason and provide a fix. If it was done by design, > I suppose the fvwm project would not be interested in this fix. It's not a fix because nothing is broken except the application. There are a few places where fvwm refreshes the focus for windows using WM_TAKES_FOCUS to the specific subwindow that had the focus and that works pretty well. Of course this works only if the application requests the right focus policy. If Tk can't handle that protocol, then a Tk application can not manage focus in its subwindows without violating the spec. Bye Dominik ^_^ ^_^ -- Dominik Vogt, mail: [EMAIL PROTECTED], phone: 0721/91374-382 Schlund + Partner AG, Erbprinzenstr. 4-12, D-76133 Karlsruhe -- Visit the official FVWM web page at <URL: http://www.fvwm.org/>. To unsubscribe from the list, send "unsubscribe fvwm" in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
