Subject: FVWM: Releasing Mouse bindings under fvwm 2.0.46

From: Ted Faber <[email-masked]>
Date: Fri, 16 Jan 1998 12:09:20 -0800

-----BEGIN PGP SIGNED MESSAGE-----

Hi, folks.

I have a problem unbinding mouse keys from fvwm which looks to be a
bug to me, but I wanted to know if I'm missing something.  First a
little context, then the relevent fvwm2rc bits, then the bug
description.  I'm running fvwm-2.0.46 on Solaris 5.5.1 on a Sparc
Ultra-1.  The X server is Openwindows-3.0.

I bind modified mouse presses (e.g. ctrl-button-1) to fvwm functions
(iconify, raise, lower) in application window contexts.  Bunches of
these "newfangled" programs want to use these events for themselves.
Rather than rewire my head and hands to use something else I want to
turn these mouse bindings on and off in fvwm.  The relevent exerpts
from my fvwm2rc are:

AddToFunc EnableMouseInWindow "I" Mouse 1 W S Raise
+	"I" Mouse 2 W S Beep
+	"I" Mouse 3 W S Lower
+	"I" Mouse 1 W C Iconify
+	"I" Mouse 2 W C Move
+	"I" Mouse 3 W C Resize
+	"I" Mouse 1 W M Focus
+	"I" Mouse 2 W M Module FvwmIdent
+	"I" Mouse 3 W M Beep
+	"I" Function WMMenu "fvwm Mouse Off" "Function DisableMouseInWindow"
+	"I" Recapture

AddToFunc DisableMouseInWindow "I" Mouse 1 W S
+	"I" Mouse 2 W S -
+	"I" Mouse 3 W S -
+	"I" Mouse 1 W C -
+	"I" Mouse 2 W C -
+	"I" Mouse 3 W C -
+	"I" Mouse 1 W M -
+	"I" Mouse 2 W M -
+	"I" Mouse 3 W M -
+	"I" Function WMMenu "fvwm Mouse On" "Function EnableMouseInWindow"
+	"I" Recapture

I include them on a menu, but you can bind them to function keys to
test this.  The bug is that if I create a window, iconify it using
control-button-1, uniconify it, and turn off the bindings, that window
does not get control-button events (or any other modified button
events).  A window started fresh when fvwm's modified mouse bindings are
off receives all button events.  (I used xev to test this.) 

The behavior I'd like is for windows to get the button events that
don't have bindings.  In any case I think all windows should recieve
the same events.

If this is a bug, I'd like to get it on the bug list.  I don't have
the time or fvwm coding experience to patch this easily.

Please cc me on replies, I'm not subscribed to the fvwm discussion
list.

- ----------------------------------------------------------------------
Ted Faber                                                [email-masked]
USC/ISI Computer Scientist                   http://www.isi.edu/~faber
(310) 822-1511 x190      PGP Key: http://www.isi.edu/~faber/pubkey.asc

--
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: Dan Espen <[email-masked]>
Date: Fri, 16 Jan 1998 16:01:36 -0500

> +	"I" Function WMMenu "fvwm Mouse Off" "Function DisableMouseInWindow"
...
> the time or fvwm coding experience to patch this easily.

For this  to be a  bug, fvwm2 would  have to be   in conflict with its
documentation.   I think  the relevant  part is  "recapture" from "man
fvwm2":

     Recapture
          Causes fvwm to recapture  all  of  its  windows.   This
          ensures  that the latest style parameters will be used.
          The recapture operation is visually disturbing.

Notice  that  "recapture" affects  "styles",  but  not  key and  mouse
bindings.

I think  keys and buttons are associated  with windows when the window
is originally  created in "add_window.c",  in the functions "GrabKeys"
and "GrabButtons".

Still, it seems like this might  be useful functionality for fvwm2, so
you never know, someone might  decide to tackle  this, now that you've
identified what you'd like to do...

> Please cc me on replies, I'm not subscribed to the fvwm discussion
Just this once...

--
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" in the body of a
message to [email-masked].
To report problems, send mail to [email-masked].

---

From: Ted Faber <[email-masked]>
Date: Fri, 16 Jan 1998 13:50:40 -0800

-----BEGIN PGP SIGNED MESSAGE-----

>          The recapture operation is visually disturbing.

I'm not worried that Recapture doesn't add the bindings.  In fact, if
the modified mouse keys are bound to fvwm functions and a window has
somehow escaped the bindings, Recapture puts them into effect.

What I'm concerned about is that executing

Bind Mouse 1 A C Iconify

and then 

Bind Mouse 1 A C -

prevents applications from getting control-button-1 events when I push
the button in the application's window.  On the other hand, a window
created after the command sequence does get those events.  The
documentation that's concerning me is:

Mouse Button Context Modifiers Function
      Defines a mouse binding, or removes the binding  if
      Function is '-'.

It seems to me that if the binding is removed the application should
see the events.  This isn't explicitly stated there, but it seems
intuitive to me, and the inconsistency between a window that has its
bindings removed and one that is created after they are removed
distresses me.

>is originally  created in "add_window.c",  in the functions "GrabKeys"

If I get time to code dive, I'll start there, thanks.