Dominik Vogt wrote:
>
> On Tue, Aug 20, 2002 at 06:02:58PM -0400, Sergey Babkin wrote:
>
> > A separate issue: something wrong seems to be going on with the focus
> > on the nested clients (such as a parent Tcl/Tk program providing a frame
> > with option -container and a child Tcl/Tk program running within this
> > frame with option -use). When the mouse pointer gets moved into the parent
> > window and then out of it, the child loses its focus. Since I use
> > the mode ClickToFocus, that should not happen (and indeed did not happen
> > with fvwm1 nor with CDE WM). This bug occurs both in the latest snapshot
> > and in 2.4.8.
> >
> > Here is a small example of a Tcl script for demonstration:
> >
> > -------------------------------
> >
> > #!/usr/local/bin/wish8.0
> > #
> > # test of a client swallowed by another client
> >
> > puts "swallow $argv"
> > if {![string compare [lindex $argv 0] {-child}]} {
> > label .l -text "internal" -bg white -fg black
> > pack .l
> > bind .l <FocusIn> ".l config -bg yellow"
> > bind .l <FocusOut> ".l config -bg white"
> > focus .l
> > } else {
> > frame .f -bd 10 -bg blue -relief sunken
> > frame .f.f -container 1
> > pack .f.f .f
> > exec $argv0 -use [winfo id .f.f] -child &
> > bind .f <FocusIn> ".f config -bg red"
> > bind .f <FocusOut> ".f config -bg blue"
> > focus .f.f
> > }
> > -------------------------------
> >
> > (you may need to edit the interpreter path according to where you have
> > wish on your system). It contains two window one in another. The outer
> > (frame) window is blue when it does not have focus and red when it
> > has focus. The inner window is white when it does not have focus and
> > yellow when it does. The outer window is hardwired to pass the
> > focus to the inner window whenever it receives the focus.
> > Normally the only possible color combinations should be "red-yellow"
> > and "blue-white" (well, except after the initial start before the focus
> > gets switched for the first time - it's an independent Tk issue). However
> > with fvwm2 many more strange combinations happen.
>
> 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. 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 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. 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.
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.
-SB
--
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 majordomo_at_fvwm.org.
To report problems, send mail to fvwm-owner_at_fvwm.org.
Received on Wed Aug 21 2002 - 14:43:27 BST