> Date: Tue, 31 Oct 1995 08:16:43 -0500 (EST)
> From: Robert Nation 885-9815 <rnation_at_mansvr.sanders.lockheed.com>
> 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
Just as a point of order, the clock could still ask for input focus, its just
that it isn't expecting the window manager to give it focus. If the
WM_TAKE_FOCUS atom is present in the WM_PROTOCOLS property then if could be in
"globally active mode" which according to my ICCCM means that it will
explicitly take input focus when it wants it.
As usual our customer has a different perception of how things should work and
wants us to only every transfer focus to windows when they open or by clicking
into a textfield contained in such windows. You can press buttons/menus etc in
other windows but still keep typing in the original window. I've used this
globally active mode to achieve the required result.
The reason why I bring this up is that fvwm doesnt seem to behave the way I
would expect it to. It all works fine under the window manager we will be
using, but I suspect fvwm doesnt like other programs moving the focus around.
--
Kit Smithers KitS_at_bartley.demon.co.uk
-------------------------------------------------------------------------------
You can now reach me at Kit_Smithers_at_msn.com, but why would you want to?
--
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 Wed Nov 01 1995 - 07:00:59 GMT