Subject: FVWM: Found another bug in FVWM 2.2

From: Dan D Niles <[email-masked]>
Date: Mon, 8 Mar 1999 16:00:29 -0600

I have the following functions and bindings in my fvwm2rc:

AddToFunc Title-Bar-Fun
+	"M"	Move
+	"D"	WindowShade
+	"C"	Raise

AddToFunc Raise-unless-Move
+	"M"	Move
+	"C"	Raise

Mouse 1		T	5	Title-Bar-Fun
Mouse 1  	WSFI	5	Raise-unless-Move

The C option works in Raise-unless-Move but not in Title-Bar-Fun.
If I remove the D option from Title-Bar-Fun, it works fine.  It worked
fine in version 2.0.46.

I would appreciate it if someone else could test this to verify that
it is a bug.

Thanks,

Dan

--
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: Tue, 9 Mar 1999 02:10:36 +0100

> If I remove the D option from Title-Bar-Fun, it works fine.  It worked

No, that works in the current CVS source. What version are you using?
Not 2.1.10 by any chance? Mouse bindings are broken there. You should
use 2.2.0 if so. '5' seems to be an exotic modifier to me. Are you sure
you are pressing the right key?

Bye

Dominik

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

---

From: Dan D Niles <[email-masked]>
Date: Tue, 9 Mar 1999 09:37:38 -0600

I am using version 2.2, as indicated in the subject.  Guess I should have
added that in the body also.

5 is modifier 5, which I have bound to that useless Window's 95 key.
The C option does work, except for this one instance.  Perhaps they
didn't get everything fixed from version 2.1.10.

Did you try the bindings listed or did you just assume that I was an
idiot because you couldn't understand my message?  Why not try the
bindings for yourself, use another modifier if 5 is too exotic for
you.

Dan D Niles

---

From: Dan D Niles <[email-masked]>
Date: Tue, 9 Mar 1999 12:37:02 -0600

Doh!  I responded to the wrong message.  This is the message I meant to 
respond to.

I tracked down the bug.  When a function has double click actions
single clicks get the wrong type.  Below (end of this message) is a
patch that fixes the bug.

Dan

> I would appreciate it if someone else could test this to verify that

--- fvwm/complex.c.orig	Tue Mar  9 12:04:57 1999
+++ fvwm/complex.c	Tue Mar  9 12:18:57 1999
@@ -179,6 +179,13 @@
       type = DOUBLE_CLICK;
       ev = &d;
     }
+  /* If a function has DOUBLE_CLICK actions, a single click results in
+   * type = ONE_AND_A_HALF_CLICKS, which causes CLICK actions to stop
+   * working.  This hack fixes it, but the way double clicks are
+   * handled should probably be fixed in a better way. 
+   * Bug fix by -DDN- (Dan D Niles [email-masked] or [email-masked]) */
+  if( type == ONE_AND_A_HALF_CLICKS ) type = CLICK; /* -DDN- */
+
   /* some functions operate on button release instead of
    * presses. These gets really weird for complex functions ... */
   if(ev->type == ButtonPress)

---

From: Dominik Vogt <[email-masked]>
Date: Wed, 10 Mar 1999 00:47:31 +0100

> +++ fvwm/complex.c	Tue Mar  9 12:18:57 1999

But do duoble clicks still work with this fix? Looking at the code
I doubt it.

Bye

Dominik

---

From: Dan D Niles <[email-masked]>
Date: Wed, 10 Mar 1999 09:22:52 -0600

> But do duoble clicks still work with this fix? Looking at the code

Yes, double clicks still work.  If you understand the code rather 
than just look at it, you will see that it should and does still work.

Dan D Niles

---

From: Dominik Vogt <[email-masked]>
Date: Wed, 10 Mar 1999 15:51:38 +0100

> than just look at it, you will see that it should and does still work.

Hey, if *you* understand the code (I tried but I couldn't), can you
tell me what this ONE_AND_A_HALF_CLICKS thing was good for?

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.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 D Niles <[email-masked]>
Date: Wed, 10 Mar 1999 10:23:04 -0600

> tell me what this ONE_AND_A_HALF_CLICKS thing was good for?

If the section of code with the ONE_AND_A_HALF_CLICKS in it were removed,
a single click would register as a double click.  It seems that either
two ButtonPress events are on the stack for a single press, or that the
ButtonPress event for the first press doesn't get removed.  The first
seems more likely.  Either way, the ONE_AND_A_HALF_CLICKS is there
to purge an extra event from the event queue.  The *correct* way to
fix this would be to figure out why the event queue isn't doing
what we would expect, and fix that first.

---

From: Dan D Niles <[email-masked]>
Date: Wed, 10 Mar 1999 10:57:18 -0600

I just re-read the code.  The problem is that the ButtonPress from the
first press is never taken off the event queue.  I will write a new
patch to fix this correctly.

---

From: Dominik Vogt <[email-masked]>
Date: Wed, 10 Mar 1999 23:50:22 +0100

> patch to fix this correctly.

Thanks! We were trying to figure out what this 1 1/2 click thing
was good for but never had thought of this. The funny thing is that
you can even put an 'O' in a function (not that it works, but anyway).

Bye

Dominik

---

From: Dan D Niles <[email-masked]>
Date: Thu, 11 Mar 1999 09:43:54 -0600

> you can even put an 'O' in a function (not that it works, but anyway).

Actually, you could pop the first press off the queue, and leave the
ONE_AND_A_HALF_CLICKS code in there.  Then O would work and be
*slightly* different from D.  There isn't anything in the docs about O
and the intent of the code seems to be to get double clicks working.
I don't see any need for distinguising between 1 1/2 clicks and 2
clicks, but it could be done.

Dan D Niles

---

From: Dominik Vogt <[email-masked]>
Date: Thu, 11 Mar 1999 15:45:24 +0100

> clicks, but it could be done.

Sure, but I don't see a use for it.

Dominik