Subject: Re: FVWM: bugs in fvwm2

From: <[email-masked]> (Charles Hines)
Date: Fri, 1 Dec 1995 09:49:55 -0500

>>>>> "Chad" == Chad Coulliette <[email-masked]> writes:

Chad> Hello Everyone (including Chuck),

Howdy.

Chad> After installing and using fvwm2 for about a week now, I have
Chad> been very impressed with its performance.

Glad to hear it.

Chad> However, I have found a few of problems that appear to be bugs
Chad> of some sort,

Of course...

Chad> 1)  When I create an rlogin button, that is

Chad> *FvwmButtons Routh xterm-sun.xpm Exec "routh" xterm -geometry
Chad> 80x40 -T routh -e rlogin -lfred routh &

Chad> The button does not pop back up afterwards, but stays stuck down
Chad> forever.  If I use rsh instead of creating an xterm locally,
Chad> then the button pops back up right away.  However, it is not
Chad> always possible to use csh due to security methods on some
Chad> workstations.  I noticed this problem with Netscape as well.  I
Chad> have a button for Netscape that always sticks.

Odd.  The line looks ok.  Use FvwmIdent to find out the Name of the
xterm when it comes up, to make sure it's being set to "routh".

Chad> 2)  I installed fvwm2 to use on a SPARCstation 20 with SunOS
Chad> 4.1.3, which acts as a server for several other machines.
Chad> Everything works fine on the 20, and on our SPARCstation 1's,
Chad> but on our SPARC IPC there is a problem with changing pages
Chad> using the mouse.  When the mouse is moved vertically off the
Chad> screen then it flips to the next screen (page) perfectly.  But,
Chad> when the the mouse is moved horizontally off the screen then it
Chad> does not flip to the next page unless the mouse is moved *VERY*
Chad> slowly.  I have tried adjusting the EdgeResistance from 0 0
Chad> through 350 100, and nothing fixed this behavior.  In my opinion
Chad> this bug is the most serious that I have seen with fvwm2 because
Chad> flipping pages by mouse motion is one of the *best* features of
Chad> fvwm2.

I've never seen this problem before.  I just played with it a little
right now, and my horizontal and vertical edge scrolling are both the
same speed, and react equally well to slow and fast mouse movement,
although an EdgeResistance w/ a low first param seemed better for fast
movement.  Not sure what to tell you here...

Chad> 3)  If the SaveDesk module is used, with a 'Read .fvwmdesk' at
Chad> the end of the .fvwm2rc file, then FvwmForm no longer works,
Chad> i.e. I have a QuitVerify module that uses FvwmForm as given in
Chad> the FvwmForm man page and this works so long as the 'Read
Chad> .fvwmdesk' is not used.  A strange bug!?

This is probably because FvwmForm doesn't use the standard config
reading function, but rather reads the .fvwm2rc itself directly.  This
has been fixed for the next release.

Chad> 4)  If FvwmBacker is used to set up some intial backgrounds with
Chad> xpmroot or xv or xsetroot, the 'xv -root -quit -max
Chad> filename.gif' is used from a menu to set a background on one
Chad> desk, then all of the desks are changed to that image.  Flipping
Chad> desks does not change back to the default background.  If
Chad> xpmroot is used from a menu, then only the current desk is
Chad> changed, but when flipping back to this desk, the default
Chad> background is back.  This is because FvwmBacker has not been
Chad> made aware of this change.  A proper cure for both of these
Chad> problems is to provide a way for menu items to send commands
Chad> directly to FvwmBacker or any other module for that matter.
Chad> Todd Fries offered a nice solution to this problem by using a
Chad> complex function and Read command with a separate file for each
Chad> background, each file containing the command to be passed to the
Chad> FvwmBacker module.

I just played with these situations, and couldn't reproduce the xv
problem (I had the 'correct' behavior, explained next).  The xpmroot
'problem' is the correct behavior.  FvwmBacker gets new desk messages
from fvwm, and runs the specified commands.  So setting the background
manually, then changing desks should cause FvwmBacker to reset it to
what it should.

If you want to manually set the backgrounds, then you should probably
kill FvwmBacker when you do (use a function that runs xv or xpmroot
and does a KillModule on FvwmBacker), and restart FvwmBacker when you
want it running again.  Or you could use the multiple config file
reread solution, which is useful for many things.

Chad> 5)  When the FvwmConfig is used to to change the default Back
Chad> and Fore colors of window borders, the FvwmButtons bar loses its
Chad> Style ClickToFocus.

I've never played with this module, but I'll look into this problem.

Chad> Has anyone else experienced these problems or does anyone have
Chad> hacks or work-arounds for them?  In my opinion, these issued
Chad> need to be addressed before an official non-beta version of
Chad> fvwm2 can be released.

When the first official release goes out, there are still going to be
several bugs.  And many people will find ones that no one else sees
and that others can't reproduce.  It (or any other program) will never
be completely bug free.  At some point (when it seems least harmful)
the bullet must be bitten and it gets officially released.

My main concern is cleaning up the make and install process (for the
most part anyways) and any easy to fix, commonly encountered bugs that
are particularly annoying, then get it out there.  It's been in beta
for quite a while.  Then take care of the rest (and the million more
that will get reported) as I (we) can.  Especially since some fairly
big changes are going to be needed to take care of some things, and
any changes (to any program) potentially introduce or uncover more
bugs.

Chuck

--
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: [email-masked] (Wichert Akkerman)
Date: Tue, 5 Dec 1995 11:32:45 +0100 (MET)

Hello!

:-> Chad> Everything works fine on the 20, and on our SPARCstation 1's,
:-> Chad> but on our SPARC IPC there is a problem with changing pages
:-> Chad> using the mouse.  When the mouse is moved vertically off the
:-> Chad> screen then it flips to the next screen (page) perfectly.  But,
:-> Chad> when the the mouse is moved horizontally off the screen then it
:-> Chad> does not flip to the next page unless the mouse is moved *VERY*
:-> Chad> slowly.  I have tried adjusting the EdgeResistance from 0 0
:-> 
:-> I've never seen this problem before.  I just played with it a little
:-> right now, and my horizontal and vertical edge scrolling are both the
:-> same speed, and react equally well to slow and fast mouse movement,
:-> although an EdgeResistance w/ a low first param seemed better for fast
:-> movement.  Not sure what to tell you here...

I've noticed the same kind of behaviour with a Sun IPC running fvwm 1.24.
Vertical edge scrolling since to work fine, but when I move the mouse
horizontally it just disappears at the side of the screen. I've got
no idea what causes this behaviour or of fvwm2 still has the same behaviour
on the IPC since I haven't compiled it yet under SunOS.

Greetings,
  Wichert.

---

From: <[email-masked]> (Charles Hines)
Date: Tue, 5 Dec 1995 09:26:36 -0500

>>>>> "Wichert" == Wichert Akkerman <[email-masked]> writes:

Wichert> Hello!
> movement.  Not sure what to tell you here...

Wichert> I've noticed the same kind of behaviour with a Sun IPC
Wichert> running fvwm 1.24.  Vertical edge scrolling since to work
Wichert> fine, but when I move the mouse horizontally it just
Wichert> disappears at the side of the screen. I've got no idea what
Wichert> causes this behaviour or of fvwm2 still has the same
Wichert> behaviour on the IPC since I haven't compiled it yet under
Wichert> SunOS.

Hm.

Well, maybe its a SPARC IPC problem then?  Especially since it's not
seen under the other SPARC's Chad mentioned above.

Do the SPARC IPC's have any kind of built in virtual desktop support
support (that makes it act like a really wide screen)?  I know IBM X
Stations have this support built in, and XFree86 under Linux has
something similiar (which caused odd problems for someone else on this
list at one point).  If it does, find out how to shut that feature off
and see if the problem goes away.  If not, I don't have any other
ideas yet...

Chuck

---

From: Mark Powell <[email-masked]>
Date: Tue, 5 Dec 1995 16:11:57 GMT

> Date: Tue, 05 Dec 1995 11:32:45 +0100 (MET)
> From: [email-masked] (Wichert Akkerman)
> 

I have a vague memory of all sorts of X problems on a Sun IPC with the
OpenWindows X/News server.  I gave up and built and installed the X11R5
sample server since I had the sources to hand.

-- 
Mark Powell, Senior Software Engineer <[email-masked]>
Primagraphics Limited, Graphics Court, Melbourn Science Park,
Melbourn, Royston, Herts SG8 6EJ, England. Tel. +44 1763 262041
--
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: [email-masked] (Robert Nation 885-9815)
Date: Tue, 5 Dec 95 11:44:13 EST

-> Chad> Everything works fine on the 20, and on our SPARCstation 1's,
>:-> Chad> slowly.  I have tried adjusting the EdgeResistance from 0 0

This is caused by a multi-screen display! try running your x server with the
-zaphod argument (see the man pages). For multi-screen displays, when
you move the mouse to the edge of the screen, it tries to switch you to
the other screen. Since fvwm is doing something similar, the two
confict.

Rob