Subject: MenuStyle gets nuked by shortcut keys

From: [email-masked]
Date: Sun, 27 Dec 1998 14:41:57 -0600 (CST)

Full_Name: Nathan Froyd
Version: 2.15
CVS_Date: 
OS: Linux 2.0.35 (RedHat 5.1)
X_Server: XFCom 2.0
Submission from: (NULL) (137.112.230.183)

I have in my .fvwm2rc the following line:

SetMenuStyle default LightGoldenrod3 SlateGray4 sienna sienna fixed anim
fvwm (DGradient 32 SlateGray4 gray3)

which works OK when I start fvwm2.

However, I also have lines of the form:

Key e A SCM Exec xemacs
Key a A SCM Exec /opt/applix/applix

scattered throughout my .fvwm2rc. Whenever I use one of those shortcut
keys, the menu
background immediately gets changed to SlateGray4 throughout.

--
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 01:34:36 +0100

> background immediately gets changed to SlateGray4 throughout.

Do you have any key binding in your config that could cause this?
Perhaps a SetMenuStyle bound to some key/mouse button? Are you
sure you properly built 2.1.5 (try make clean first if not).

Bye

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

---

From: Patrick Rogan <[email-masked]>
Date: Mon, 28 Dec 1998 04:11:54 -0500

FYI:  I'm currently using fvwm2 x2.0.46, and canceling a window move
works exactly as the user _expects_ in this bug report, #59 under
"enhancements" on the bug tracking page.  This is contrary to the reply
posted by domivogt.

> Full_Name: Danek Duvall
> ...
>
> If I initiate a window move with the mouse by clicking on the titlebar,
> then trying to cancel the move by hitting Escape does not result 
> in the window immediately popping back into place. 

Hitting escape while the mouse button is still held down DOES cause the
window to snap back and cancels the move function.

Here is the relevant part of my .fvwmrc

AddToFunc Move-or-RaiseLower-or-shade	"C" RaiseLower
+					"D" WindowShade
+					"M" Move

Mouse 1		TS       A       Move-or-RaiseLower-or-Shade

Therefore, this apparently broke sometime after v. 2.0.46

~p@

---

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

On Mon, Dec 28, 1998 at 04:11:54AM -0500, [email-masked] wrote:
> "enhancements" on the bug tracking page.

> This is contrary to the reply posted by domivogt.

It is? What reply do you refer to?

> Therefore, this apparently broke sometime after v. 2.0.46

Since I'm the one who wrote the code I know exactly what
happened and is happening (it is exactly what I wanted).
Whatever the exact symptoms are, the problem is:
If we snap the window back immediately (by leaving the move
function), all mouse events accumulated will go to the
application window. Especially the button release may be
harmful. I see no easy way to fix this with the current code.

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: Patrick Rogan <[email-masked]>
Date: Mon, 28 Dec 1998 19:53:33 -0500

The term "pending mouse movements" confused me for some reason.  
Anyhow, a little more explanation highlighted the reasoning behind the
change.

:)

~p@