Subject: Notification: incoming/775

From: [email-masked]
Date: Wed, 12 Sep 2001 04:20:49 -0500

FVWM Bug Tracking notification

new message incoming/775

Message summary for PR#775
	From: [email-masked]
	Subject: FvwmForm behavioural anomaly.
	Date: Wed, 12 Sep 2001 04:20:44 -0500
	0 replies 	0 followups

====> ORIGINAL MESSAGE FOLLOWS <====

>From [email-masked] Wed Sep 12 04:20:49 2001
From: [email-masked]
To: [email-masked]
Subject: FvwmForm behavioural anomaly.
Date: Wed, 12 Sep 2001 04:20:44 -0500

Full_Name: George Beckett
Version: 2.4.0
CVS_Date: 
OS: Solaris 2.6 SPARC
X_Server: Openwindows 3.6
Submission from: (NULL) (130.159.248.36)

Just built the new version of Fvwm (ver. 2.4.0) on our network, both for
Solaris 2.6 and Redhat Linux 6.2. We use a standard FvwmForm for a logout
prompt - taken from FvwmForm man page - details of config. listed at end
of message. Using fvwm 2.2.4 there are no problems. However, for fvwm
2.4.0
actions are taken immediately when a button (either Cancel or Logout in
this case) is pressed, and not when it is released. This behaviour is only
on Solaris installation (I've tried using both Sun cc and gcc), the Linux
installation works fine. My temporary fix is to use the FvwmForm from
2.2.4,
which seems to cause no problems.

Relevant config is:

*QuitVerify: GrabServer
*QuitVerify: Font -*-lucida-*-r-*-*-14-*-*-*-*-*-*-*
*QuitVerify: ButtonFont -*-lucida-*-r-*-*-14-*-*-*-*-*-*-*
*QuitVerify: Fore black
*QuitVerify: Back lightgrey
*QuitVerify: ItemFore black
*QuitVerify: ItemBack lightgrey
*QuitVerify: Command Beep
*QuitVerify: Line center
*QuitVerify: Text "Do you really want to logout?"
*QuitVerify: Line center
*QuitVerify: Button quit "Logout"  ^M
*QuitVerify: Command quit
*QuitVerify: Button quit "Cancel"  ^[
*QuitVerify: Command Nop

--
Visit the official FVWM web page at <URL:http://www.fvwm.org/>.
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: Wed, 12 Sep 2001 14:07:34 -0400

> which seems to cause no problems.

I'm the culprit on this one.
Actually, I like the immediate action.
Looking at FvwmScript, I get the impression it does the same thing.

I remember the old logic didn't work very well, perhaps it wasn't
robust enough.  So far, all the solutions that look like they
might be robust seem to be pretty big too.

Anyone have an opinion about whether this should be "fixed" and
if so, what to use as a model?

-- 
Dan Espen
444 Hoes Lane  Room RRC 1C-214           E-mail: [email-masked]
Piscataway, NJ 08854                     Phone: (732) 699-5570
--
Visit the official FVWM web page at <URL:http://www.fvwm.org/>.
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: Tim Phipps <[email-masked]>
Date: Fri, 14 Sep 2001 17:36:06 +0100

> Looking at FvwmScript, I get the impression it does the same thing.

It's OK as long as the action doesn't result in the window going away.
What happens then is the window underneath gets a button release event
and may get confused.
> if so, what to use as a model?

I think it should be fixed to behave like buttons in the widgets of most
toolkits i.e a button press in the button area causes the button to go
in and the pointer to be grabbed. The event gets launched when the
button is released. You can do fancy stuff like raise the button and
disable the action if the pointer leaves the button area but it's
optional. The Fvwm menus poped up by titlebar buttons do this nicely.

Cheers,
Tim.