Subject: FVWM: Re: bugs

From: Dominik Vogt <[email-masked]>
Date: Wed, 21 Aug 2002 01:08:39 +0200

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.

Bye

Dominik ^_^  ^_^

 --
Dominik Vogt, [email-masked]
Reply-To: [email-masked]
--
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-masked].
To report problems, send mail to [email-masked].

---

From: Sergey Babkin <[email-masked]>
Date: Wed, 21 Aug 2002 15:41:54 -0400

> it.  If the problem persists once the application has been fixed,

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

---

From: Dominik Vogt <[email-masked]>
Date: Thu, 22 Aug 2002 11:21:50 +0200

> Dominik Vogt wrote:

[snip]

> 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

>        subwindows
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Isn't that quite clear?

>                   or  can  decline  the offer of the focus.  For
> 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 

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.

> 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-masked], 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-masked].
To report problems, send mail to [email-masked].

---

From: Sergey Babkin <[email-masked]>
Date: Thu, 22 Aug 2002 14:20:08 -0400

> to cope with Tk which is totally broken in many aspects of window

Why would it be a bug in fvwm ?

> likes if the application fails to use the WM_TAKES_FOCUS protocol.

Correct. And it would be nice if it liked to handle even those applications
gratiously.
 
> It's not a fix because nothing is broken except the application.

What if we call it a "feature" ?

-SB

-- 
Sergey Babkin                             [email-masked]
Escalations Research Group, Caldera - NJ  (908)790-2385
--
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-masked].
To report problems, send mail to [email-masked].