Subject: RE: FVWM: New problems since 2.3.6

From: "Adye, TJ (Tim) " <[email-masked]>
Date: Thu, 3 May 2001 03:01:19 +0100

Hi Dan,

Thanks for the message.

> Does   clicking  on the  titlebar  vs.  clicking   in  the window  act
> differently?

No, they do the same thing: clicking in window or titlebar both raise the
window as one would like (in fact this is one of the improvements since
2.3.6, which often didn't raise the window if one only clicked in the
window). The problem is that 2.3.31 is too eager to raise the window: when
the active X-window is behind a native window, it is raised even if the
cursor just passes through it. This is only a problem with the active
window, and only when a native window is in front (when there's just
X-windows involved it all works perfectly). Unfortunately this behaviour can
make fvwm nearly unusable, as a small native window in front of a large
X-window becomes nearly inaccessible as it's always pushed back when one
tries to get at it.

> Have you looked at the various "ClickRaises" options?

All the ones I could find: as well as ClickToFocus, I normally have
ClickToFocusPassesClick, ClickToFocusRaises, and MouseFocusClickRaises
enabled, but I tried turning them off with no luck - though maybe there's a
magic combination I've missed.

> > 2) Deiconising or switching to a window (by menu or taskbar) does an
> > annoying full screen refresh. This doesn't happen when the window is
> > selected by just clicking on it.
> 
> I don't see this.  Are you using some kind of function to
> deiconify that includes a refresh?

Not that I can tell. I'm using the sample-95 setup with a few edits. For
example, I have

*FvwmTaskBarAction Click1 DeiconifyFocusAndRaise
AddToFunc DeiconifyFocusAndRaise I Iconify off
+                                I Focus
+				         I Raise

> > 3) In my FvwmButtons (edited a little to conform to the new syntax) I
have
> > buttons like
> > 
> >      *BarButtons(Title XTerm, Icon rterm.xpm, Action `Exec "XTerm" exec
xterm`)
> > 
> I'm not sure, but it looks like there too many execs after action.

I tried removing the second exec, but that didn't help. I use the second
exec to prevent the shell process hanging around unnecessarily.

These still look like bugs. Should I add them to the bug tracking system?

Thanks,
Tim.

==============================  cut here  ==============================
Tim Adye, BaBar/DELPHI Groups, Particle Physics Dept.,     _   /|
          Rutherford Appleton Laboratory, UK.              \'o.O'   Oop!
e-mail:   [email-masked] or VXCERN::ADYE (HEPNET/SPAN)  =(___)=  Ack!
WWW:      http://hepwww.rl.ac.uk/Delphi/Adye/homepage.html    U  Thphft!
--
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: Dominik Vogt <[email-masked]>
Date: Sun, 6 May 2001 14:46:31 +0200

> X-window becomes nearly inaccessible as it's always pushed back when one

I searched up and down the code but I can't find any way how
simply moving the pointer over the focused window could trigger
raising or lowering windows.  You said that turning of the
RaiseOverNativeWindows option 'fixes' the problem.  This proves
that the RaiseOrLowerWindow() function is called when the pointer
enters the window because it is the only place where the option is
evaluated.  But fvwm does not call this function.  I can think of
several possible explanations:

 1) Exceed raises the window.  Is there perhaps some setting in
    Exceed for this?
 2) FvwmEvent is doing this.
 3) FvwmAuto is running and configured to do this.
 4) The application raises itself.  This would mean that this
    occurs only for some applications.
 5) Other reasons?

> AddToFunc DeiconifyFocusAndRaise I Iconify off

Please post your config file so we can try it out.

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: Mikhael Goikhman <[email-masked]>
Date: Sun, 6 May 2001 13:41:45 +0000

> > > deiconify that includes a refresh?

Maybe the problem is iconifying animation not working well under Exceed?
You may turn it off in "Settings/Animation".

> Please post your config file so we can try it out.

Dominik, you may try it by running "FvwmScript FvwmScript-Setup95",
.fvwm2rc will be back-upped.

It is basically system.fvwm2rc-sample-95 divided to multiple files.

Regards,
Mikhael.

---

From: Dan Espen <[email-masked]>
Date: Sun, 06 May 2001 10:55:06 -0400

> You may turn it off in "Settings/Animation".

I've used Exceed quite a bit and I don't see any full screen
refreshes.

There are some settings that might affect this.

I run windows in truecolor mode.  If you don't run in truecolor mode
and a new color is allocated, windows does some colormap balancing
the might look like a full screen refresh.

Under Exceed, Xconfig, Screen Definition, Server Visual I selected
"Auto Select".  You can pick TrueColor or PsuedoColor.  Combined with
the windows setting, a mismatch might cause problems.

Under  Exceed, Xconfig,  Video,  there are  some  Palette options.   I
picked Defer Changes and Optimize To  Reduce Flashing On Focus Change.
I've  also got  Preserve  System Colors  selected, Preallocate  system
colors in default   colormap  selected and  Enable System  Pixels  not
selected.  Since I'm running with TrueColor I don't think these
setting affect me much.

I use FvwmAnimate with the builtin IconBox with no problem.

-- 
Dan Espen
444 Hoes Lane  Room RRC 1C-214           E-mail: [email-masked]
Piscataway, NJ 08854                     Phone: (732) 699-5570
--
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: Dan Espen <[email-masked]>
Date: Sun, 06 May 2001 11:08:34 -0400

Dominik Vogt <[email-masked]> writes:
> > No, they do  the same  thing: clicking in   window or titlebar  both
> > raise the  window as one  would  like (in  fact this  is one of  the
> > improvements since 2.3.6, which often didn't raise the window if one
> > only clicked in the window). The problem is that 2.3.31 is too eager
> > to raise  the window: when the  active  X-window is behind  a native
> > window, it is raised even if the cursor just passes through it. This
> > is  only a problem with the  active window, and   only when a native
> > window is in   front (when there's  just  X-windows involved it  all
> > works perfectly). Unfortunately  this behaviour can make fvwm nearly
> > unusable, as a  small native  window  in front of  a large  X-window
> > becomes  nearly  inaccessible as  it's always  pushed  back when one
> > tries to get at it.
> 

I don't see one.  I'm using Exceed 6.2.

>  3) FvwmAuto is running and configured to do this.

Using FvwmAuto, Fvwm windows raise over native windows as they should.
Native windows don't raise over Fvwm windows unless you click on an
exposed part (as they should).  Once a native window has focus,
an Fvwm window won't raise over a native window until I click on the
frame, or until I move from one Fvwm window into another.  This makes
some sense, the first fvwm window to get focus doesn't know the native
window is in the way so it has no reason to raise itself.

I don't have any RaiseOverNative settings.

>     occurs only for some applications.

In Windows there is a TweakUI package that changes the focus model
from ClickFocus to PointerFocus.  I had problems with it, so I'm not
using it.  I don't know what that would do.