Subject: obscure bugs?

From: Dominik Vogt <[email-masked]>
Date: Mon, 28 Dec 1998 01:48:25 +0100

In the last two weeks we got a large number of bug
reports that seem to be really strange:

1) SetMenuStyle setting is lost when a certain key
   combination is pressed (MenuFace)

2) SnapAttraction does not work during Restart.

3) A mouse binding on window titles seems to be
   ignored.

4) Key bindings are lost over time.

5) Multiple FvwmPagers seem to slow down X a lot on
   a slow machine

6) XGetImage is very slow sometimes

7) Restart failed to read my config file once
   (an hour ago).

And all these bugs (except 5 and 6 perhaps) can not
be reproduced by anyone. This stinks! Something must
be terribly awry in the code. Any ideas how to start
on this?

Perhaps 5/6 and 2/7 are separate from 1/3/4. There
must be something very wrong with bindings at least.

Bye

Dominik
-- 
Dominik Vogt, [email-masked]
Reply-To: [email-masked]

--
Visit the official FVWM web page at <URL:http://www.hpc.uh.edu/fvwm/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [email-masked].
To report problems, send mail to [email-masked].

---

From: Dan Espen <[email-masked]>
Date: Mon, 28 Dec 1998 09:43:27 -0500

> must be something very wrong with bindings at least.

Starting with my 2.1.7 download of just a few minutes ago,
my root window keybindings for warping to windows started selecting
the wrong window:

AddToFunc Warp "I" Next [$0] Iconify -1
+	       "I" Next [$0] WarpToWindow 24p 24p
+              "I" None [$0] Beep

Key r R N Warp rlogin

(Key "r" on the root should select the "rlogin" window.  Instead
it selects each window I have in turn.)  When I have no "rlogin" window
it should beep.  It never beeps.

Looks like we don't want to announce this beta.

--
Dan Espen                                Phone: (732) 699-5570
444 Hoes Lane  Room RRC 1C-214           E-mail: [email-masked]
Piscataway, NJ 08854
--
Visit the official FVWM web page at <URL:http://www.hpc.uh.edu/fvwm/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [email-masked].
To report problems, send mail to [email-masked].

---

From: Dan Espen <[email-masked]>
Date: Mon, 28 Dec 1998 10:55:15 -0500

> Looks like we don't want to announce this beta.

Looking thru the ChangeLog, I found this:

1998-12-24  Dominik Vogt  <[email-masked]>

	* fvwm/builtins.c (MatchesContitionMask): rewrote the contition so that
	a mere mortal can read it (costs a few bytes though).

	* fvwm/builtins.c (MatchesContitionMask):
	* fvwm/icons.c (DeIconify):
	(Iconify): bugfix for transient iconification bug

So I reverted  "MatchesContitionMask"   to its original  state,  which
"fixed" the problem.

Which leaves a quandry.  The original logic is unparsable.  (I must be
an  ordinary mortal.)   Was it necessary  to  rewrite this to fix  the
"transient iconification  bug" or was this  just re-written because it
was unparsable?

If I am really going to have to understand that code, my head is going
to hurt.

Would it be better  to  create 2.2  with the "transient  iconification
bug" rather than make such drastic change at this time?

---

From: Dominik Vogt <[email-masked]>
Date: Mon, 28 Dec 1998 19:58:32 +0100

On Mon, Dec 28, 1998 at 10:55:15AM -0500, Dan Espen wrote:
> >... 

Both. Basically I did no more than breaking this condition
into several statements. Seems I did something wrong there :(

> bug" rather than make such drastic change at this time?

I don't think so. Once you have understood what's going on
it isn't *this* complicated. I'll look at the code. Probably
something very obvious I've done wrong.

Bye

Dominik
-- 
Dominik Vogt, Hewlett-Packard GmbH, Dept. BVS
Herrenberger Str.130, 71034 Boeblingen, Germany
phone: 07031/14-4596, fax: 07031/14-3883, [email-masked]
--
Visit the official FVWM web page at <URL:http://www.hpc.uh.edu/fvwm/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [email-masked].
To report problems, send mail to [email-masked].

---

From: Dominik Vogt <[email-masked]>
Date: Mon, 28 Dec 1998 20:10:59 +0100

> bug" rather than make such drastic change at this time?

Dan, could you make the next package then? I'm a bit
tired of working on fvwm and will not do much more than
fixing this bug today. I'll let you know when the fix is ready
(or when I've given up).

Bye

Dominik

P.S.: please reply to the list

---

From: Dan Espen <[email-masked]>
Date: Mon, 28 Dec 1998 14:35:11 -0500

> fixing this bug today. I'll let you know when the fix is ready

No problem.

Are we doing this the right way?

Shouldn't we put  stuff  in the  tree, let a   few days pass  for  CVS
downloads and tests, then tag and create a package?

Since we have no real 2.1.7 yet, after you commit your changes, can't
I re-tag this as 2.1.7 and try again?  (I'll try if no one points out
my error before I try.)

---

From: Dominik Vogt <[email-masked]>
Date: Mon, 28 Dec 1998 20:46:12 +0100

> downloads and tests, then tag and create a package?

Probably we should, but what will we do in the meantime?
The change that caused the problem was a small bugfix. We can't 
possibly hold back a new release because of ten changed lines
every time (?) At the moment we still have the delay between
building the tarball and announcing it. Perhaps if we always
let pass a day or two before announcing it we are safe enough.
What do you think? Up to now we didn't announce a release with
a real show stopper in thanks to this delay.

> I re-tag this as 2.1.7 and try again?  (I'll try if no one points out

Sure you can. There is no 2.1.7 tag right now. I don't
understand your question. I built the 2.1.6 tarball. 2.1.7
is just the version number in configure.in.

In principle we could even retag the source with version-2_1_6
without too much trouble (-F option to rtag). Perhaps that is
better than having a stale version that will definitely be
downloaded as soon as it shows up somewhere. On the other
hand it might not be worth the trouble (configure.in has
to bechanges and perhaps other stuff?).

Bye

Dominik

---

From: Dan Espen <[email-masked]>
Date: Mon, 28 Dec 1998 15:21:45 -0500

> Probably we should, but what will we do in the meantime?

I'm  not understanding  this question.  At   this time, I  don't think
anything should be committed unless its essential to 2.2.

> every time (?) At the moment we still have the delay between

Only essential fixes should go in.  Rewriting routines shouldn't
go in unless necessary.  Thats why I questioned it.
(I'm not saying it wasn't necessary, just asking the question.)

> a real show stopper in thanks to this delay.

I think we can save ourselves some work by getting a stable CVS
before going on to packaging.

> is just the version number in configure.in.

Sorry, I meant 2.1.6.

> to bechanges and perhaps other stuff?).

Since you've already updated configure.in, its simpler
to go ahead and make the next release 2.1.7.

I suggest we go this way:

Get your changes committed.  (Take your time.)

Let 2 working days pass for CVS downloads and testing.  If nothing
develops, tag, create package, test package and announce.  This may
take another day or 2.  Due to the nature of this week, 2 days this
week may not be enough.  Perhaps Jason has a way of letting us know
how many CVS downloads there are in a given time interval.  I'd like
to think we have at least 5 CVS downloads before packaging...

If anything gets committed  in the interval, before the
package is created, start over.

Looking thru Jitterbug, I don't see anything that would get in the way
of 2.2.  I think we want to go to great lengths to hold back on any
changes right now.  It would be ideal if 2.2 is identical to 2.1.7.

---

From: Dominik Vogt <[email-masked]>
Date: Mon, 28 Dec 1998 22:05:56 +0100

> anything should be committed unless its essential to 2.2.

See below.

> (I'm not saying it wasn't necessary, just asking the question.)

I would go a bit further as you can see in what bugs I've been
fixing in the last weeks.
 
> package is created, start over.

That is what I meant with 'what will we do in the meantime?'. I
don't think fvwm is stable enough to switch into this mode of
operation.

> changes right now.  It would be ideal if 2.2 is identical to 2.1.7.

What I want to see fixed/done first is:

 - the key/mouse binding problems (not all in Jitterbug)
 - the XPM problems (probably in 'configure', bugs #31, #40
   and perhaps others)
 - this XGetImage problem I encountered (because of its
   high visibility)
 - apply latest signal handling patches
 - verify the 'growing windows' bugfix (I don't think it
   is completely fixed. The tkbiff growing rapidly problem
   is not verified, bug #28)
 - verify the num-lock/key binding bugfix (bug #54)

Not this important, but I think they should still be fixed
before 2.2.

 - install-strip problem (bug #33)
 - closing a panel closes FvwmButtons (perhaps too difficult)
 - FvwmCpp does not know where cpp is (bug #95)
 - crash with xclock (bug #56)

Bye

Dominik

---

From: Dan Espen <[email-masked]>
Date: Tue, 29 Dec 1998 10:49:03 -0500

>  - crash with xclock (bug #56)

I can't say I agree with all these items being necessary for 2.2.

I'll try to help however.

I was unable  to  reproduce bug number  56 with  2.1.6.  If  you don't
object, I'll move it to fixed.   (There was unsubstantiated conjecture
that  it was a  signal handling problem.  As I  understand  it you and
Chris did some signal handling changes.)

Perhaps more correct would be to move it to unreproducible, would that
get it off the 2.2 hit list?

---

From: Dominik Vogt <[email-masked]>
Date: Wed, 30 Dec 1998 09:03:07 +0100

> I can't say I agree with all these items being necessary for 2.2.
 
So, where don't you agree? We can talk about everything.

Let me explain my motivation behind these:

1) the key/mouse binding problems (not all in Jitterbug)

Really strange. I don't believe all these people were
fantasizing. I don't want 2.2 before it is clear what
caused these problems.

One of the top priorities for me.

2) the XPM problems (probably in 'configure', bugs #31,
   #40 and perhaps others)

Probably the worst problem we have at the moment. There
have been at least four or five complaints about pixmap
problems.

3) this XGetImage problem I encountered

Well, we can of course document this problem in the 
manpage/BUGS/FAQ, but unfortunately this will happen
as soon as you use a gradient menu face and forget to
turn off all other item hilighting (i.e. it's the
default with gradients). Anyway, some work has to be
done here, whatever the solution will be.

4) apply latest signal handling patches

Either we use the latest signal handling patches or back
them out completely. Leaving them in an 'alpha' state is
the worst thing we can do here.

5) verify the 'growing windows' bugfix

We have no confirmation if tkbiff still may grow until it
is as wide as the whole desk. I don't think it is fixed
because I didn't do anything there. It is probably not
related to the 'growing windows' bug. My guess is that
tkbiff or fvwm2 has a bug with configure requests that
cause this. I have created this kind of behaviour myself
when experimenting with HandleConfigureRequest and thus
think it it probably a fvwm2 issue.

If it is a general problem it has to be addressed, if
it's tkbiff only it may wait (although I think it should
still be fixed before 2.2).

6) verify the num-lock/key binding bugfix (bug #54)

I never understood where the problem came/comes from.
I backed out some changes I did in ParseBindEntry but
since I don't see this bug I can't verify it. I've
written mails until my fingers were sore, but the
reporters (several independent reports) don't seem to
care if it is fixed or not (i.e. nobody replies to my
questions if it works now).

Since it breaks core functionality and has a high
visiblility this one is a must.

7) install-strip problem (bug #33)

I think this was an automake bug. I remember some comment
by Paul (PDS) about this (is that tight, Paul?) and the
error message from the report seems to confirm this too.

I wonder how other autoconf'ed programs do this if they
have multiple directories where executables are built.
Perhaps we could create symbolic links tho the correct
install-sh in the distribution?

If we can't fix it we have to document it.

8) closing a panel closes FvwmButtons

We have had at least three independent reports about this.
I think this justifies spending some time on that before
2.2. If it is not too difficult we should fix it.

9) FvwmCpp does not know where cpp is (bug #95)

10) crash with xclock (bug #56)

> I was unable  to  reproduce bug number  56 with  2.1.6.

Does this imply that you could reproduce it with some
earlier version?

> If  you don't object, I'll move it to fixed.

If you could reproduce it before and it's gone with 2.1.6,
go ahead. If not we should address it. I didn't do anything
apart from trying to reproduce it (which I could not).

> (There was unsubstantiated conjecture

No, I didn't touch the signal handling code. I only applied the
fixes. I agree that the patches may have fixed it, but we didn't
verify that.

> get it off the 2.2 hit list?

I feel quite uncomfortable to do it this way (provided that
is really is unreproducible) bacause we did not address this
bug. I have not the slightest idea how likely this will happen.
At least we should try to contact Philip (J. Hollenback
<[email-masked]>) before doing this.

--

There are some mails about problems with 2.1.x that
should be investigated too:

11) hanging up asmodem kills FvwmButtons (perhaps related to 8)
12) this 'serious bug' RedHat found (I'd like to see the patch).
13) the FvwmCommandS problem discussed recently

Bye

Dominik