Subject: Re: FVWM: Here is a fvwm-2.0.38 bug.

From: Ed Williams <[email-masked]>
Date: Mon, 30 Oct 1995 15:53:16 -0500 (EST)

On Mon, 30 Oct 1995, Randall S. Winchester wrote:

> When I startup "dclock", and move my mouse over the window, the border 
> does not change color, as a sign of focus change. If the dclock is very near
> an xterm then I can move from the xterm to the dclock and the focus is still
> in the xterm. This is very odd behaviour. Other WM's do not have this 
> problem. Any ideas?

Programs like clocks and xloads do not accept the keyboard focus -- they
can (and do) tell this to the window manager so that the window manager 
doesn't waste time or effort dumping characters down the bit bucket! 

-.-. --.- -.-. --.- -.. . -. -.... --.. --. -. -.... --.. --. .-.-. -.-
Ed Williams (N6ZG)      | work: [email-masked]
[email-masked]    | WWW:  http://www.infinet.com/~ewilliam/
=======================================================================

--
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: Greg Veres <[email-masked]>
Date: Mon, 30 Oct 1995 15:45:24 -0500

> in the xterm. This is very odd behaviour. Other WM's do not have this 

This is actually a desirable feature that ONLY FVWM has. I suspect that you
have enabled SloppyFocus policy and have the Style for dclock to include
ClickFocus. 

What this means to the user is that:

Sytle: The only way to get focus in a clickFocus window is to actually
click on it. The rationale behind this is that there are certain windows
(clocks, xloads etc) that you do not want to get focus arbitrarily when the
pointer moves over it.

SloppyFocus: when the pointer moves from a window onto the root window (or
a window with click focus) the focus stays in the window you are
leaving. This is a really great feature because you can be working in a
window and have the mouse bumped and you will still be typing in the window
you think you are.

I beleive the sample .fvwmrc files set this behaviour. Look for the
following lines in your .fvwmrc file if you do not like the behaviour.

Style "*lock"       NoTitle, NoHandles, Sticky, WindowListSkip,ClickToFocus
Style "*"           SloppyFocus

-Greg

---------------------------------------------------------------------
Greg Veres ([email-masked])         | You got your whole life to
Computer Graphics Lab, University Of Waterloo| do something and thats not
http://www.cgl.uwaterloo.ca/~gveres          | very long.  - Ani Difranco
--
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: "Randall S. Winchester" <[email-masked]>
Date: Mon, 30 Oct 1995 16:34:56 -0500 (EST)

Thanks for this very nice reply, however this is not the problem/feature.

I do not have ClickToFocus set anywhere, and infact clicking on the dclock
does not do any good. For that matter I do not have SloppyFocus set anywhere
either. This truely looks like a bug to me. The mouse buttons do what
they are supposed to though over the dclock, it is just the keyboard
that either does not respond or responds in another window.

Randall

---

From: Tod McQuillin <[email-masked]>
Date: Mon, 30 Oct 1995 20:43:52 -0600 (CST)

> doesn't waste time or effort dumping characters down the bit bucket! 

This is true, but not of dclock.  Dclock uses keystrokes for various 
things, for instance, 'q' to quit, 's' to display seconds, and 'd' to 
display the date.

Incidentally, I don't notice the anomalous behaviour described by the 
original poster.  Perhaps a compiler bug?
--
Tod McQuillin

---

From: [email-masked] (Chris Taylor)
Date: Tue, 31 Oct 1995 05:08:26 +0000 (GMT)

> doesn't waste time or effort dumping characters down the bit bucket! 

I've always used ordinary pointer focus, even before I started using
fvwm. When I used mwm (or 4dwm, or even twm, for that matter) with
pointer focus, I could move the pointer into an xload or xclock
window, then execute window manager commands using the keyboard.
Fvwm has never allowed me to issue keyboard-bound WM commands to those
two clients, and I've been using fvwm since version 1.20. It's
something that's always irked me, but never enough to *really*
complain. :-) Whenever I've wanted to terminate one of those two
clients through fvwm commands, I've always had to pick "close" or
"delete" from my root menu, then click on the window in question. With
any other window manager I've used, I just moved the pointer into the
window and pressed alt-f4: the window closes.

Of course, my setup could be screwy. In fact, it is -- I do some heavy
m4 processing on it before passing it to fvwm. But even before I
started using m4 on my .fvwmrc file, fvwm acted this way. Now I see
I'm not the only one to experience this behavior. Fvwm behaves in this
situation for me as it does for Randall Winchester. If I move the
pointer into, say, my xclock, it doesn't receive the focus, regardless
of whether or not another window had the focus beforehand.

So, I'm right back where I (and others) have started. What causes this
behavior? As I said, it's probably something in my setup. I know I
make those clients sticky with no titles or borders, and I remove them
from the window list and circulation list. (I'm going by my memory; my
setup is at work and I'm writing this from home.) Could any of those
attributes contribute to this condition? I don't have explicit focus
enabled for anything in my setup -- just a 'style "*" pointerfocus' at
the top of my styles.

-- 
Christopher W. Taylor   |   [email-masked]   |   God is an iron.
You know you've been on the Net too long when you're reading a book
next to your computer and you press the computer's space bar at the
end of the book's page.

---

From: Henrique Martins <[email-masked]>
Date: Mon, 30 Oct 1995 22:18:56 -0800

> things, for instance, 'q' to quit, 's' to display seconds, and 'd' to 

  I had to fix this for sxpm once.  The problem exists for all Xt based
  programs that initialize the top level shell like this:

    toplevel = 
      XtInitialize (name,
                    "DClock",
                    options,
                    XtNumber(options),
                    &argc,
                    argv);

  as the XtNinput resource will be set to False, by default, and FVWM will
  not pass any input to to that program, as the ICCM requires.  I believe
  that FVWM maybe the only WM that complies to this requirement.

  To fix this add to dclock.c, an include for

     #include <X11/Shell.h>

  change the line that declares:
    Arg arg;
  to
    Arg arg[1];

  and add, after the call to initialize, the following two lines:

    XtSetArg (arg[0], XtNinput, True);
    XtSetValues (toplevel, arg, 1);

  That ought to do it.

  -- Henrique ([email-masked])

---

From: [email-masked] (Robert Nation 885-9815)
Date: Tue, 31 Oct 95 08:22:53 EST

>things, for instance, 'q' to quit, 's' to display seconds, and 'd' to 

Just because it uses keystrokes doesn't mean that the program was set up 
correctly. Use xprop to find out for sure.
Rob

---

From: [email-masked] (Robert Nation 885-9815)
Date: Tue, 31 Oct 95 08:16:43 EST

>that either does not respond or responds in another window.

The dclock probably has set the hint :

WM_HINTS(WM_HINTS):
                Client accepts input or input focus: False
 
xclock does this, so I bet dclock does too.

This means that the clock should not ever get the keyboard focus. Most window
managers ignore this property, because a number of applications set it
incorrectly. So, fvwm tried to move the focus from an xterm to the clock,
but found that the clock did not want focus. At this point one could argue
about whether the focus should move to root or back to the xterm, but I don't
think that it matters much. If want the standard broken behavior (give focus to
the clock), then you need to set 
Style "*" Lenience
or just
Lenience
depending on which version of fvwm you have.

Rob

---

From: Peter Funk <[email-masked]>
Date: Tue, 31 Oct 1995 08:14:59 +0100 (MEZ)

Ed Williams wrote:
ew> Programs like clocks and xloads do not accept the keyboard focus -- they
ew> can (and do) tell this to the window manager so that the window manager 
ew> doesn't waste time or effort dumping characters down the bit bucket!

This ist fine.  But why does the fvwm pager (at least in version
1.24r) not do the same ?  Are there any special keyboard functions
only possible, when the pager has the keyboard-focus ?  Using fvwms
'sloppyfocus' would be a lot more useful, if the the pager wouldn't 
grap the keyboard focus away from the previous window.

Regards, Peter