Hello FVWM mailing list,
Recently I downloaded fvwm-2.0.46 and compiled it
for Linux/Alpha 2.0.32/X11R6.
This version (and possibly many previous versions I have not looked
at) has an annoying habit when destroying windows. It is moving the
focus when the window which is being destroyed DOES NOT have the
focus.
Here's what happens:
I have fvwm set up in click-to-focus mode.
My application creates windows, and changes the focus between windows
as needed. When the application is about to close one of its windows
(which currently has the focus), the focus is first pushed to the next
window which the application thinks should have it, then the original
window is closed.
In this way, the app is trying to keep the window manager from just
arbitrarily shifting the focus to some unknown window.
I looked in fvwm's code, and discovered this fragment in
HandleUnmapNotify() of events.c (There is a similar fragment in
Destroy() of misc.c)
if((Tmp_win == Scr.Focus)&&(Tmp_win->flags & ClickToFocus))
{
if(Tmp_win->next)
{
HandleHardFocus(Tmp_win->next);
}
else
SetFocus(Scr.NoFocusWin,NULL,1);
}
if(Scr.Focus == Tmp_win)
SetFocus(Scr.NoFocusWin,NULL,1);
Tmp_win is getting closed, and Scr.Focus is the last window that
fvwm gave focus to, but not necessarily the window with current
focus. When Tmp_win == Scr.Focus, BUT is NOT the window
with current focus, then fvwm resets the focus. This behavior
is annoying, since an application loses control over which window
has the focus whenever it closes a window.
It seems to me that fvwm should check to make sure that the window
being closed does indeed have the focus before trying to shift
it to another window.
Any insight would be appreciated,
-Todd Squires
--
Visit the official FVWM web page at <URL:http://www.hpc.uh.edu/fvwm/>.
To unsubscribe from the list, send "unsubscribe fvwm" in the body of a
message to majordomo_at_hpc.uh.edu.
To report problems, send mail to fvwm-owner_at_hpc.uh.edu.
Received on Sun Jan 11 1998 - 11:59:22 GMT