Subject: FVWM: Re: beta 2.0.43 ready

From: Dan Calle <[email-masked]>
Date: Sun, 14 Jul 1996 21:00:59 -0400 (EDT)

First I have a question and then I'll get on with the bug report.

It's not in the FAQ so - what exactly is the purpose of libfvwm2.a?
Is it only for those who wish to write modules or what?

"Charles Hines" <[email-masked]> wrote:
[snip]
> I'd like to make this the last beta before the first official
> release (2.1.0).  So let me know what other problems you find with
> it so I can clean it up (especially build and doc problems).  Bear
> in mind that I can't fix ALL of it's bugs, especially the one's I
> can't reproduce...

Background info: 
I'm running Digital UNIX 3.2c on an AlphaStation and 3.0 on a DEC
3000/300LX Alpha.  Both systems have X11R5 and the XPM libs.  Fvwm was
compiled "out of the box" with xmkmf;make Makefiles;make;make install;
make install.man - all I changed in Fvwm.tmpl were the destination
directories for the install.

Bug 1:

This had appeared on the DEC 3000 since 2.0.42 but didn't show up on
the AlphaStation 'til 2.0.43.  Often, edgescroll won't work.  I'll
drag and drag and it won't switch pages.  If I then hit Control-right,
it works fine, and thereafter edgescroll works normally.  I'm not sure
if the problem stays fixed 'til I next log out and back in again
though.  The relevant lines from my .fvwm2rc file are:

EdgeScroll              100 100
EdgeResistance          200 25

Key Left        A       C       Scroll -100 0
Key Right       A       C       Scroll +100 +0
Key Up          A       C       Scroll +0   -100
Key Down        A       C       Scroll +0   +100

Bug 2:

xlock -mode flame has started dying after a few minutes of running.
The error is:

	/bin/sh: 1416 Floating exception 

where the number is the PID of:

	/bin/sh -c xlock -nolock -mode flame

Previously the only mode I'd ever had trouble with was "galaxy".  I
don't know which of the last few versions this might have appeared in
because I don't run XLock that often.  I can't really say for certain
that it's fvwm but I haven't changed anything else that would affect
it.

The line in my .fvwm2rc is:

+                       "flame"         Exec xlock -nolock -mode flame

I haven't tried this on the AlphaStation though.

Bug 3:

The bug I mentioned in another message in which one of my xterms
wasn't getting the Styles hasn't been fixed and may be worse.  I'm not
sure it was supposed to have been fixed but "Simple patch to help take
care of some timing bugs" might be referring to it.  To reiterate, the
first xterm I run in my .xsession often, especially on the slower
machine, does not get any Styles (not *, not xterm, nothing) even
though the other xterms (also run from the .xsession after a short
"sleep" delay...probably not starting until after fvwm2 is already
running) do get the Styles.  Restarting fvwm2 fixes this problem but,
if I do it before some of the other delayed jobs in the .xsession
finish, some of them will never finish and I end up with no xclock or
xpostit+ or something.

The reason I say this may be worse is that it's now happening more
often on the AlphaStation, which is faster and hardly ever needs to
swap.  In 2.0.42, it usually happened on the slower, lower RAM,
machine and only occasionally on the fast machine.

Request for 2.1.0:

Not a bug report and I know the TO-DO list mentions resurrecting
StubbornPlacement but, in case it's not implicitly grouped with
StubbornPlacement, the return of StubbornIconPlacement would also be
very nice - especially the feature that caused icons to reposition
themselves to avoid windows when the Scroll function was called.  I
had gotten used to not having to search for icons under windows.

Thanks much,

-- 
Dan Calle                                  SysAdmin and Research Assistant
                                   Physics Department, Sweet Briar College
Email: [email-masked]              Talk/Finger: [email-masked]
Web Page: http://csugrad.cs.vt.edu/~dcalle/            Finger for PGP key.
--
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 [email-masked].
To report problems, send mail to [email-masked].

---

From: "Charles Hines" <[email-masked]>
Date: Mon, 15 Jul 1996 12:10:04 -0400

>>>>> "Dan" == Dan Calle <[email-masked]> writes:

Dan> First I have a question and then I'll get on with the bug report.
Dan> It's not in the FAQ so - what exactly is the purpose of libfvwm2.a?
Dan> Is it only for those who wish to write modules or what?

Basically (it's used to link fvwm itself too).  It really doesn't need
to be installed, although I believe it currently is installed.

>> in mind that I can't fix ALL of it's bugs, especially the one's I

Dan> Background info:
Dan> I'm running Digital UNIX 3.2c on an AlphaStation and 3.0 on a DEC
Dan> 3000/300LX Alpha.  Both systems have X11R5 and the XPM libs.  Fvwm was
Dan> compiled "out of the box" with xmkmf;make Makefiles;make;make install;
Dan> make install.man - all I changed in Fvwm.tmpl were the destination
Dan> directories for the install.

Dan> Bug 1:

Dan> This had appeared on the DEC 3000 since 2.0.42 but didn't show up on
Dan> the AlphaStation 'til 2.0.43.  Often, edgescroll won't work.  I'll
Dan> drag and drag and it won't switch pages.  If I then hit Control-right,
Dan> it works fine, and thereafter edgescroll works normally.  I'm not sure
Dan> if the problem stays fixed 'til I next log out and back in again
Dan> though.  The relevant lines from my .fvwm2rc file are:
....

I've seen some reports about this, but cannot reproduce it myself.  I
think I need to put a remark in the BUGS file about it.

Just out of curiousity, is everyone else who is seeing it running on
DEC machines as well?

Dan> Bug 2:

Dan> xlock -mode flame has started dying after a few minutes of running.
Dan> The error is:

Dan>    /bin/sh: 1416 Floating exception

Dan> where the number is the PID of:

Dan>    /bin/sh -c xlock -nolock -mode flame

Dan> Previously the only mode I'd ever had trouble with was "galaxy".  I
Dan> don't know which of the last few versions this might have appeared in
Dan> because I don't run XLock that often.  I can't really say for certain
Dan> that it's fvwm but I haven't changed anything else that would affect
Dan> it.
....

Actually, I think this is a bug with xlock.  Do you see the same
problems if you run xlock by hand?  I've seen problems like this with
xlock in various modes core dumping (or locking up the machine
entirely) on PowerPC based machines, but haven't had a chance to
investigate yet.

Dan> Bug 3:

Dan> The bug I mentioned in another message in which one of my xterms
Dan> wasn't getting the Styles hasn't been fixed and may be worse.
Dan> I'm not sure it was supposed to have been fixed but "Simple patch
Dan> to help take care of some timing bugs" might be referring to it.
Dan> To reiterate, the first xterm I run in my .xsession often,
Dan> especially on the slower machine, does not get any Styles (not *,
Dan> not xterm, nothing) even though the other xterms (also run from
Dan> the .xsession after a short "sleep" delay...probably not starting
Dan> until after fvwm2 is already running) do get the Styles.
Dan> Restarting fvwm2 fixes this problem but, if I do it before some
Dan> of the other delayed jobs in the .xsession finish, some of them
Dan> will never finish and I end up with no xclock or xpostit+ or
Dan> something.

Dan> The reason I say this may be worse is that it's now happening more
Dan> often on the AlphaStation, which is faster and hardly ever needs to
Dan> swap.  In 2.0.42, it usually happened on the slower, lower RAM,
Dan> machine and only occasionally on the fast machine.

The "Simple patch..." does not address this problem.  As I said in a
note a few days ago (I believe), I know what is causing this problem
and have a good idea how to fix it.

In a nutshell, fvwm isn't Grabbing the server soon enough and new
windows are popping up after the list of windows to traverse has been
made (which is why they don't get updated).  The least destructive fix
that I can think of is to move the initial XGrabServer call up a
little, but some of the functions that are called below it make calls
to XGrabServer and XUngrabServer, which don't keep track of the total
grab request count (ie the first XUngrabServer could mess things up
again), so I'm creating my own wrappers around XGrab/UngrabServer to
keep track of the count and only ungrab after all corresponding grabs
& ungrabs are done which should fix the problem.  It'll be in 2.1.0,
although I may mail out a patch for people to try early.

Dan> Request for 2.1.0:

Dan> Not a bug report and I know the TO-DO list mentions resurrecting
Dan> StubbornPlacement but, in case it's not implicitly grouped with
Dan> StubbornPlacement, the return of StubbornIconPlacement would also be
Dan> very nice - especially the feature that caused icons to reposition
Dan> themselves to avoid windows when the Scroll function was called.  I
Dan> had gotten used to not having to search for icons under windows.

Neither of them will be in 2.1.0, but I have had the latter in mind
for part of the "better icon handling needed?" entry.

Chuck

---

From: Joey Hess <[email-masked]>
Date: Mon, 15 Jul 1996 13:45:14 -0400 (EDT)

> Just out of curiousity, is everyone else who is seeing it running on

No, I'm running linux on a pentium, and I get the same bug. I have to
click on a different virtual desktop on the pager, and then edgescroll
starts working again, and seems to keep working until I restart fvwm.
I've had this problem in 2.0.42 and .43. 

-- 
#!/usr/bin/perl -i\$q='$q',\$p='$p';eval\$q.\$\^I#\n"#    [email-masked]
$q='print"$p$^I\n',$p='#!/usr/bin/perl -i';eval$q.$^I#        Joey Hess
                      "He. He. He." - - Herman Toothrot

---

From: Manoj Kasichainula <[email-masked]>
Date: Mon, 15 Jul 1996 14:14:52 -0400 (EDT)

[snip]
> I've had this problem in 2.0.42 and .43. 

Ditto. Have this problem under sundry kernels of Linux and HP-UX. 2.0.42
and 43. If you need to check out an fvwm2rc to duplicate this, check out" 
(same URL I posted before)

http://dosa.ini.cmu.edu/~manojk/fvwm2rc

_______________________________________________________________________
Manoj Kasichainula - [email-masked] | "Some people have entirely
http://dosa.ini.cmu.edu/~manojk/           |  too much free time on
Linux: 0% of the GPFs at 0% of the price   |  their hands."
Finger for PGP public key & Geek Code      |   - spaf

---

From: Eli Burke <[email-masked]>
Date: Mon, 15 Jul 1996 15:43:41 -0400 (EDT)

> > I have to click on a different virtual desktop on the pager, and then 
> > edgescroll starts working again, and seems to keep working until I restart
> 
> and 43. If you need to check out an fvwm2rc to duplicate this, check out

	Using this .fvwm2rc file I was able to duplicate this error. It
does NOT happen with my .fvwm2rc file. I'm currently eliminating things
to see if I can narrow down what causes the error.
	While doing all this I thought I'd mention some things I noticed:
there is an error in the fvwm2 man page: "fvwm2 -f" is now "fvwm2 -cmd" and
the man page should reflect that. :) Also, I like how the failsafe mode 
works now. You get one menu with quit on it. Perhaps it should pop up a
menu box and say that the .fvwm2rc file was not found?
	Ok... after playing around for about a half hour, I think I have
an idea about what is going wrong. I suspect that everyone who encouters 
this problem uses FvwmCpp. 
	When I got the above listed .fvwm2rc file I had to switch to 
starting Fvwm with FvwmCpp. As soon as I did that, I was unable to switch
virtual screens. I winnowed away at the .fvwmrc file until I had only this:
In my .xsession: exec fvwm2 -cmd "FvwmCpp /home/staff/eburke/.fvwm2rc"
----------------cut--------------------------
ModulePath /usr/lib/X11/fvwm2/
HilightColor            linen SteelBlue4
AddToFunc "InitFunction"
+       "I" Module FvwmPager 0 0
AddToFunc "RestartFunction"
+       "I" Module FvwmPager 0 0
AddToMenu "Utilities" "Utilities" Title
+       "Exit Fvwm" Popup Quit-Verify
AddToMenu "Quit-Verify" "Really Quit Fvwm?" Title
+       "Yes, Really Quit" Quit
+       "Restart fvwm" Restart fvwm2
Mouse 1         R       A       Menu Utilities Nop
----------------cut--------------------------
	The shortest possible fvwm2rc file that doesn't fail. And each time
I restarted I still had trouble. Then, switching my startup back so that it
does NOT use FvwmCPP caused the problem to vanish.
	I would have tried running my normal .fvwm2rc through FvwmCpp as a
backup test, but it barfs on it for some reason and gives me the failsafe.

	So this doesn't exactly solve the problem but it should help
pinpoint it somewhat. Anyone care to tell us if FvwmM4 has a similar
problem?

-- 
Eli Burke
[email-masked] 
http://csugrad.cs.vt.edu/~eburke/

---

From: Joey Hess <[email-masked]>
Date: Mon, 15 Jul 1996 16:02:12 -0400 (EDT)

> pinpoint it somewhat. Anyone care to tell us if FvwmM4 has a similar

Yes, it does. At least, I experience this problem, and I use FvwmM4.

-- 
#!/usr/bin/perl -lisubstr($_,39+38*sin++$y/9,2)=$s        [email-masked]
for($s='  '||McQ;$_='JOEY HESS 'x8;print){eval$^I}           Joey Hess
                      "He. He. He." - - Herman Toothrot

---

From: Dave Goldberg <[email-masked]>
Date: Mon, 15 Jul 1996 16:03:11 -0400

>>>>> Eli Burke writes:

[Loss of EdgeScroll problem suspected to be related to FvwmCpp]

> pinpoint it somewhat. Anyone care to tell us if FvwmM4 has a similar

I don't see this problem with FvwmM4.

--
Dave Goldberg
Post: The Mitre Corporation\MS B305\202 Burlington Rd.\Bedford, MA 01730
Phone: 617-271-3887
Email: [email-masked]

---

From: Dan Calle <[email-masked]>
Date: Mon, 15 Jul 1996 16:26:30 -0400 (EDT)

> >>>>> "Dan" == Dan Calle <[email-masked]> writes:
[question about libfvwm2.a]
> to be installed, although I believe it currently is installed.

Actually the default is not to install it - which I had been following
blindly since I didn't know what it was.

[snip]
[snip]
> problems if you run xlock by hand?  

Yes.

> I've seen problems like this with xlock in various modes core
> dumping (or locking up the machine entirely) on PowerPC based
> machines, but haven't had a chance to investigate yet.

I had too, but as I said, only with galaxy mode and never this quickly
- also I don't think it was the same error.  I haven't updated xlock
in over a year so if this new error is caused a bug in xlock, then
somehow it wasn't triggered by 1.24r.

[snip]

One more thing, which I think I posted a long time ago but isn't in
BUGS or TO-DO, is that when I do something that closes a window (hit
return in a dialog box, click on a close or cancel button, whatever),
often the window manager gets "stuck" with the filled-circle cursor
and nothing responds (keystrokes, edgescroll, whatever) until I click
somewhere to "unstick" it.

---

From: Dan Calle <[email-masked]>
Date: Mon, 15 Jul 1996 16:29:26 -0400 (EDT)

Now that I've finally subscribed...

> Yes, it does. At least, I experience this problem, and I use FvwmM4.

I'll second that.

Just to add a detail, edgescroll *never* works right after I log in,
even if I restart fvwm.  But as soon as I hit a key combination that
calls Scroll, it starts working and, as far as I can tell, seems to
continue working.  As a counterpoint, and this was the case with 1.24r
as well, calling Scroll with a key combination often stops working
after quitting Netscape, but will start working again after I use the
mouse to edgescroll.  I presume it's a keymapping bug with Netscape
but I mention here in case there's an easy fix from within fvwm.

---

From: "Charles Hines" <[email-masked]>
Date: Mon, 15 Jul 1996 16:52:43 -0400

>>>>> "Eli" == Eli Burke <[email-masked]> writes:

>> http://dosa.ini.cmu.edu/~manojk/fvwm2rc

Eli>    Using this .fvwm2rc file I was able to duplicate this error. It
Eli> does NOT happen with my .fvwm2rc file. I'm currently eliminating things
Eli> to see if I can narrow down what causes the error.

Eli>    While doing all this I thought I'd mention some things I
Eli> noticed: there is an error in the fvwm2 man page: "fvwm2 -f" is
Eli> now "fvwm2 -cmd" and the man page should reflect that. :)

I know - I realized that just after I uploaded the tar file, which is
why I put the patch for that at the bottom of the announcement and on
the web page (didn't I?).

Eli> Also, I like how the failsafe mode works now.  You get one menu
Eli> with quit on it. Perhaps it should pop up a menu box and say that
Eli> the .fvwm2rc file was not found?

There are error messages output that indicate that actually, although
they aren't quite visible.  I was going to make the menu title be
something like "Read failed - builtin menu", but perhaps a simple
error dialog would be good.  I'll see what I can whip up (or at least
change the menu title).

Also, I think I'll add something like "Do you have an rc file now?
Restart fvwm" to that default menu, so you can try again without
completely exitting.

Eli>    Ok... after playing around for about a half hour, I think I have
Eli> an idea about what is going wrong. I suspect that everyone who encouters
Eli> this problem uses FvwmCpp.
Eli>    When I got the above listed .fvwm2rc file I had to switch to
Eli> starting Fvwm with FvwmCpp. As soon as I did that, I was unable to switch
Eli> virtual screens. I winnowed away at the .fvwmrc file until I had only this:
Eli> In my .xsession: exec fvwm2 -cmd "FvwmCpp /home/staff/eburke/.fvwm2rc"
....
Eli>    The shortest possible fvwm2rc file that doesn't fail. And each time
Eli> I restarted I still had trouble. Then, switching my startup back
Eli> so that it does NOT use FvwmCPP caused the problem to vanish.
Eli>    I would have tried running my normal .fvwm2rc through FvwmCpp as a
Eli> backup test, but it barfs on it for some reason and gives me the failsafe.

Eli>    So this doesn't exactly solve the problem but it should help
Eli> pinpoint it somewhat.

Yup - it gives me something to try anyways.  I'll look into it when I
get a chance and see if this allows me to reproduce it.

Thanks,
Chuck

---

From: Jason L Tibbitts III <[email-masked]>
Date: 15 Jul 1996 16:03:14 -0500

>>>>> "EB" == Eli Burke <[email-masked]> writes:

EB> While doing all this I thought I'd mention some things I noticed: there
EB> is an error in the fvwm2 man page: "fvwm2 -f" is now "fvwm2 -cmd" and
EB> the man page should reflect that. :)

Everyone should check the web page (URL after every message) when they
think they've found bugs; you may be able to get a quick fix.  This is
right there at the top of the latest news section, with patch.  Perhaps the
current bug list should be there too.
-- 
      Jason L. Tibbitts III - [email-masked] - 713/743-8684 - 221SR1
System Manager:  University of Houston High Performance Computing Center
                1994 PC800 "Kuroneko"      DoD# 1723
--
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 [email-masked].
To report problems, send mail to [email-masked].

---

From: Steffen Hansen <[email-masked]>
Date: Tue, 16 Jul 1996 10:29:19 +0000 (GMT)

> http://dosa.ini.cmu.edu/~manojk/fvwm2rc

I have the problem with Linux too. Since 2.0.39 i believe. As posted 
earlier i have made a minimal .fvwm2rc that shows the problem. It does 
nothing but start FvwmPager. I found out that the bug only shows up when 
i use a preprocessor.

Here is the minimal .fvwm2rc:

# This enables paging when called with:
# fvwm2 -f "Read /home/stefh/test.fvwm2rc"
# But *not* when preprocessed:
# fvwm2 -f "FvwmM4 /home/stefh/test.fvwm2rc"
# fvwm2 -f "FvwmCpp /home/stefh/test.fvwm2rc"

DeskTopSize 2x2

AddToFunc "InitFunction" "I" Module FvwmPager 0 0

--------------
Steffen Hansen                            |
email: [email-masked], [email-masked] |1 + 1 = 3, for large values of 1
URL:   http://www.dit.ou.dk/~stefh        |

---

From: "Charles Hines" <[email-masked]>
Date: Tue, 16 Jul 1996 09:05:57 -0400

>>>>> "Jason" == Jason L Tibbitts <[email-masked]> writes:

Jason> Everyone should check the web page (URL after every message)
Jason> when they think they've found bugs; you may be able to get a
Jason> quick fix.

Yes - I highly recommend this course of action as well.  I thought I
had put statements to that effect in the files included in the
distribution, but apparently not (must have just been in some note or
newsgroup post).  I'll make sure I do for 2.1.0.

Jason> This is right there at the top of the latest news section, with
Jason> patch.

That patch is at the bottom of the announcement as well.

Jason> Perhaps the current bug list should be there too.

Yes it should be and will be shortly.  How did I miss that?

Thanks,
Chuck