Subject: Beep when opening menus

From: Uwe Pross <[email-masked]>
Date: Fri, 16 Jan 2004 10:50:08 +0100

Hi there,

A couple of weeks  ago  I  reported  an  nerving  beep  when
opening  FvwmWindowList  or  menus  of some programs. In the
last days I used FrameMaker which shows this behaviour quite
often  when  a  submenu  is  opened and closed. I added some
debug statement to 2.5.7 to see where the beep  comes  from.
It says that the beep comes from functions.c [987]: 

	/* we have to grab buttons before executing immediate actions because
	 * these actions can move the window away from the pointer so that a
	 * button release would go to the application below. */
	if (!GrabEm(CRS_NONE, GRAB_NORMAL))
	{
		func->use_depth--;
		fprintf(stderr,"*** FVWM Bell: %s line %d ***\n", __FILE__, __LINE__);
		cf_cleanup(&depth, arguments);
		return;
	}

I have no idea what this code does. The beep in conjuntion
with FvwmWindowList comes from the same source.

Cheers, Uwe
-- 
  ,_,   For personal reply/mail put "fvwm"
 (O,O)  in the subject.
 (   )  Otherwise I won't receive your mail.
--"-"----------------------------------------
--
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: Dominik Vogt <[email-masked]>
Date: Fri, 16 Jan 2004 13:13:34 +0100

> with FvwmWindowList comes from the same source.

The code grabs the pointer before executing any complex function.
As it fails, another application must have already grabbed the
pointer.  Is it essential to grab the pointer before starting the
menu as it may otherwise not get the button release event which is
important for menu operation.

Ciao

Dominik ^_^  ^_^

---

From: Uwe Pross <[email-masked]>
Date: Fri, 16 Jan 2004 13:25:10 +0100

Hi there,

On 16 Jan 2004 at 13:13:34 +0100, Dominik Vogt wrote:

> The code grabs the pointer before executing any complex
> function. As it fails, another application must have
> already grabbed the pointer. Is it essential to grab the
> pointer before starting the menu as it may otherwise not
> get the button release event which is important for menu
> operation.

Okay. Is there a way to find out which application has
grabbed the pointer?

Cheers, Uwe

---

From: Dominik Vogt <[email-masked]>
Date: Fri, 16 Jan 2004 13:52:17 +0100

> Okay. Is there a way to find out which application has

Perhaps if you describe exactly what you are doing.

Ciao

Dominik ^_^  ^_^

---

From: Uwe Pross <[email-masked]>
Date: Fri, 16 Jan 2004 14:26:01 +0100

Hi there,

> Perhaps if you describe exactly what you are doing.

Nothing special I guess: 

Fvwm is running. A couple of applications have been started.
I do a middle click on the root window which is defined as:

Mouse 2 R A Module  FvwmWinList -transient
Mouse 2 A 4 Module  FvwmWinList -transient

(http://www-user.tu-chemnitz.de/~uwp/Ablage/beep.jpg)

When FvwmWinList is opened I wait for 2 seconds while moving
the mouse pointer up and down over FvwmWinList until 2 beeps
occur. 

The problem does not occur if I run fvwm with an empty
config. If I find the time I could try to find out which
parts of my config causes this problem.

Cheers, Uwe

---

From: Olivier Chapuis <[email-masked]>
Date: Fri, 16 Jan 2004 14:58:58 +0100

> 		cf_cleanup(&depth, arguments);

Use

	fprintf(stderr,"*** FVWM Bell: Abort function %s\n", action);

in the place of

the you will know which function cause the beep (maybe a scheduled
function?).

Regards, Olivier

---

From: Dominik Vogt <[email-masked]>
Date: Fri, 16 Jan 2004 15:20:35 +0100

> the mouse pointer up and down over FvwmWinList until 2 beeps

Um, it's FvwmWinList of course.  It grabs the pointer when run in
transient mode, forcing you to close it before you can continue
working on the desktop.  The -transient option is meant to be used
this way:

  1. Click to open FvwmWinList.
  2. Drag pointer to item you want to activate.
  3. Select entry by releasing the mouse.
  4: FvwmWinList closes and releases the pointer.

You probably have soething running that sends commands to fvwm
while the pointer is grabbed.  Maybe FvwmWinList should grab the
whole X server.

Ciao

Dominik ^_^  ^_^

---

From: Uwe Pross <[email-masked]>
Date: Fri, 16 Jan 2004 16:57:28 +0100

Hi there,

>   4: FvwmWinList closes and releases the pointer.

FvwmWinList opens when I release the mouse pointer. When I
keep the mouse button pressed a little clock apears after a
while but not FvwmWinList. 

> while the pointer is grabbed.  Maybe FvwmWinList should grab the

Could it be that this is caused by FvwmEvent? After
disabling it the the prob seems to be gone.

Here is my setup:

#---------------------------------------------------------------------
# Events
#---------------------------------------------------------------------
DestroyFunc CurrentPageFocusFunc
AddToFunc CurrentPageFocusFunc I Next (CurrentPage State 2) Focus NoWarp
+ I None (CurrentPage Focused) Prev (CurrentPage !Iconified !Sticky) Focus NoWarp

DestroyFunc CurrentDeskFocusFunc
AddToFunc CurrentDeskFocusFunc
+ I Current FlipFocus

DestroyFunc MarkWindowAsActiveFunc
AddToFunc MarkWindowAsActiveFunc I Current (!Iconified) All (CurrentPage !Focused) State 2 False
+ I Current (!Iconified) State 2 True

DestroyModuleConfig FvwmEvent*
*FvwmEvent: Cmd Function
*FvwmEvent: new_page CurrentPageFocusFunc 
*FvwmEvent: new_desk CurrentDeskFocusFunc
*FvwmEvent: destroy_window CurrentPageFocusFunc
*FvwmEvent: focus_change MarkWindowAsActiveFunc

Any suspicions?

Cheers, Uwe

---

From: Uwe Pross <[email-masked]>
Date: Fri, 16 Jan 2004 17:21:22 +0100

Hi there,

> 	fprintf(stderr,"*** FVWM Bell: Abort function %s\n", action);

I got:

*** FVWM Bell: functions.c line 987 [MarkWindowAsActiveFunc] ***

which comes from FvwmEvent. So I guess it is my fault :-\

I disable it for now.

Cheers, Uwe

---

From: Olivier Chapuis <[email-masked]>
Date: Sat, 17 Jan 2004 00:36:43 +0100

> which comes from FvwmEvent. So I guess it is my fault :-\

I do not think that it is your fault :o)

If you use my version of FVWM you never get these beeps (and the
function will be executed). But, for some reasons dominik does not
want that your setup work. The last thread on this subject start here:

ven 07 nov   Olivier Chapuis Re: FVWM: gkrellm and FVWM v2.5.8

on the fvwm workers list (there was an other thread on this subject
during the summer). I attach a patch (small) against the current cvs
which always execute totally immediate function.

I do not understand what you want to do with your FvwmEvent, but you
can apply the patch and see if it causes problem (when you use your
transient FvwmWinList or FrameMaker).

Regards, Olivier
Index: fvwm/functions.c
===================================================================
RCS file: /home/cvs/fvwm/fvwm/fvwm/functions.c,v
retrieving revision 1.260
diff -u -r1.260 functions.c
--- fvwm/functions.c	5 Jul 2003 01:37:47 -0000	1.260
+++ fvwm/functions.c	16 Jan 2004 23:24:24 -0000
@@ -79,6 +79,7 @@
 	FunctionItem *last_item;         /* last item in function */
 	char *name;                      /* function name */
 	unsigned int use_depth;
+	Bool already_grab_warn;
 } FvwmFunction;
 
 /* Types of events for the FUNCTION builtin */
@@ -120,7 +121,7 @@
 }
 
 /*
- * Defer the execution of a function to the next button press if the context is
+ * Defer the execution of a function to the next button press if the context
  * C_ROOT
  *
  *  Inputs:
@@ -153,6 +154,11 @@
 	if (wcontext != C_ROOT && wcontext != C_NO_CONTEXT && fw != NULL &&
 	    wcontext != C_EWMH_DESKTOP)
 	{
+		if (Scr.flags.is_executing_complex_function &&
+		    trigger_evtype == ButtonPress)
+		{
+			trigger_evtype = ButtonRelease;
+		}
 		if (FinishEvent == ButtonPress ||
 		    (FinishEvent == ButtonRelease &&
 		     trigger_evtype != ButtonPress))
@@ -875,6 +881,8 @@
 	exec_context_change_mask_t mask;
 	int trigger_evtype;
 	XEvent *te;
+	Bool need_ungrab = False;
+	Bool grab_fast = True;
 
 	if (cond_rc == NULL)
 	{
@@ -960,6 +968,17 @@
 			{
 				do_allow_unmanaged_immediate &= fi->flags;
 				ImmediateNeedsTarget = True;
+				if (!grab_fast)
+				{
+					break;
+				}
+			}
+		}
+		if (fi->condition != CF_IMMEDIATE)
+		{
+			grab_fast = False;
+			if (ImmediateNeedsTarget)
+			{
 				break;
 			}
 		}
@@ -986,12 +1005,46 @@
 	/* we have to grab buttons before executing immediate actions because
 	 * these actions can move the window away from the pointer so that a
 	 * button release would go to the application below. */
-	if (!GrabEm(CRS_NONE, GRAB_NORMAL))
+	if (grab_fast)
 	{
-		func->use_depth--;
-		XBell(dpy, 0);
-		__cf_cleanup(&depth, arguments, cond_rc);
-		return;
+		if (!GrabEmWithAttempts(CRS_NONE, GRAB_NORMAL, 1))
+		{
+			/* execute the function anyway */
+			if (1 || !func->already_grab_warn)
+			{
+				func->already_grab_warn = True;
+				fvwm_msg(
+					WARN, "ComplexFunction",
+					"Cannot grab the cursor when "
+					"executing %s", action);
+			}
+		}
+		else
+		{
+			need_ungrab = True;
+		}
+	}
+	else
+	{
+		if (!GrabEm(CRS_NONE, GRAB_NORMAL))
+		{
+			if (1 || !func->already_grab_warn)
+			{
+				func->already_grab_warn = True;
+				fvwm_msg(
+					WARN, "ComplexFunction",
+					"Cannot grab the cursor, abort "
+					"%s execution", action);
+			}
+			func->use_depth--;
+			XBell(dpy, 0);
+			__cf_cleanup(&depth, arguments, cond_rc);
+			return;
+		}
+		else
+		{
+			need_ungrab = True;
+		}
 	}
 	exc2 = exc_clone_context(exc, &ecc, mask);
 	__run_complex_function_items(
@@ -1025,7 +1078,10 @@
 	{
 		func->use_depth--;
 		__cf_cleanup(&depth, arguments, cond_rc);
-		UngrabEm(GRAB_NORMAL);
+		if (need_ungrab)
+		{
+			UngrabEm(GRAB_NORMAL);
+		}
 		return;
 	}
 
@@ -1039,7 +1095,10 @@
 		{
 			func->use_depth--;
 			__cf_cleanup(&depth, arguments, cond_rc);
-			UngrabEm(GRAB_NORMAL);
+			if (need_ungrab)
+			{
+				UngrabEm(GRAB_NORMAL);
+			}
 			return;
 		}
 	}
@@ -1110,7 +1169,10 @@
 	 * function will receive MotionNotify events with a button held down!
 	 * The results are unpredictable.  E.g. rxvt interprets the
 	 * ButtonMotion as user input to select text. */
-	UngrabEm(GRAB_NORMAL);
+	if (need_ungrab)
+	{
+		UngrabEm(GRAB_NORMAL);
+	}
 #endif
 	fev_set_evpos(&d, x, y);
 	fev_fake_event(&d);
@@ -1125,8 +1187,10 @@
 	 */
 	func->use_depth--;
 	__cf_cleanup(&depth, arguments, cond_rc);
-	UngrabEm(GRAB_NORMAL);
-
+	if (need_ungrab)
+	{
+		UngrabEm(GRAB_NORMAL);
+	}
 	return;
 }
 
@@ -1143,6 +1207,7 @@
 	tmp->last_item = NULL;
 	tmp->name = stripcpy(name);
 	tmp->use_depth = 0;
+	tmp->already_grab_warn = False;
 	Scr.functions = tmp;
 
 	return tmp;
@@ -1277,7 +1342,7 @@
 	return;
 }
 
-void find_func_t(char *action, short *func_t, unsigned char *flags)
+void find_func_t(char *action, short *func_t, FUNC_FLAGS_TYPE *flags)
 {
 	int j, len = 0;
 	char *endtok = action;
Index: fvwm/misc.c
===================================================================
RCS file: /home/cvs/fvwm/fvwm/fvwm/misc.c,v
retrieving revision 1.145
diff -u -r1.145 misc.c
--- fvwm/misc.c	25 Aug 2003 06:47:08 -0000	1.145
+++ fvwm/misc.c	16 Jan 2004 23:24:25 -0000
@@ -80,17 +80,6 @@
 	return;
 }
 
-/* ---------------------------- interface functions ------------------------ */
-
-int GetTwoArguments(
-	char *action, int *val1, int *val2, int *val1_unit, int *val2_unit)
-{
-	*val1_unit = Scr.MyDisplayWidth;
-	*val2_unit = Scr.MyDisplayHeight;
-
-	return GetTwoPercentArguments(action, val1, val2, val1_unit, val2_unit);
-}
-
 /*
  * Grab the pointer.
  * grab_context: GRAB_NORMAL, GRAB_BUSY, GRAB_MENU, GRAB_BUSYMENU,
@@ -102,7 +91,7 @@
  */
 #define DEBUG_GRAB 0
 #if DEBUG_GRAB
-void print_grab_stats(char *text)
+static void print_grab_stats(char *text)
 {
 	int i;
 
@@ -117,7 +106,7 @@
 }
 #endif
 
-Bool GrabEm(int cursor, int grab_context)
+Bool __GrabEm(int cursor, int grab_context, int attempt)
 {
 	int i = 0;
 	int val = 0;
@@ -180,18 +169,18 @@
 			grab_win = Scr.Root;
 		}
 		/* retry to grab the busy cursor only once */
-		rep = 2;
+		rep = (attempt)? attempt:2;
 		break;
 	case GRAB_PASSIVE:
 		/* cannot happen */
 		return False;
 	case GRAB_FREEZE_CURSOR:
 		grab_win = (PressedW != None) ? PressedW : Scr.NoFocusWin;
-		rep = 2;
+		rep = (attempt)? attempt:2;
 		break;
 	default:
 		grab_win = Scr.Root;
-		rep = NUMBER_OF_GRAB_ATTEMPTS;
+		rep = (attempt)? attempt:NUMBER_OF_GRAB_ATTEMPTS;
 		break;
 	}
 
@@ -218,11 +207,12 @@
 		default:
 			/* If you go too fast, other windows may not get a
 			 * chance to release any grab that they have. */
-			i++;
 			if (grab_context == GRAB_FREEZE_CURSOR)
 			{
+				i++;
 				break;
 			}
+			i++;
 			if (i < rep)
 			{
 				usleep(1000 * TIME_BETWEEN_GRAB_ATTEMPTS);
@@ -246,6 +236,28 @@
 	return True;
 }
 
+/* ---------------------------- interface functions ------------------------ */
+
+int GetTwoArguments(
+	char *action, int *val1, int *val2, int *val1_unit, int *val2_unit)
+{
+	*val1_unit = Scr.MyDisplayWidth;
+	*val2_unit = Scr.MyDisplayHeight;
+
+	return GetTwoPercentArguments(action, val1, val2, val1_unit, val2_unit);
+}
+
+Bool GrabEm(int cursor, int grab_context)
+{
+
+	return __GrabEm(cursor, grab_context, 0);
+
+}
+
+Bool GrabEmWithAttempts(int cursor, int grab_context, int attempts)
+{
+	return __GrabEm(cursor, grab_context, attempts);
+}
 
 /*
  *
Index: fvwm/misc.h
===================================================================
RCS file: /home/cvs/fvwm/fvwm/fvwm/misc.h,v
retrieving revision 1.129
diff -u -r1.129 misc.h
--- fvwm/misc.h	29 Jun 2003 19:53:23 -0000	1.129
+++ fvwm/misc.h	16 Jan 2004 23:24:25 -0000
@@ -61,6 +61,8 @@
 
 Bool GrabEm(
 	int cursor, int grab_context);
+Bool GrabEmWithAttempts(
+	int cursor, int grab_context, int attempts);
 Bool UngrabEm(
 	int ungrab_context);
 int GetTwoArguments(

---

From: Dominik Vogt <[email-masked]>
Date: Mon, 19 Jan 2004 10:00:16 +0100

On Sat, Jan 17, 2004 at 12:36:43AM +0100, Olivier Chapuis wrote:
> want that your setup work.

Would you *please* stop spreading these rumours?  I really don't
understand why you have to provoke this argument again.  And it's
useless too, since if we keep haggling over features that won't be
implemented in 2.6 anyway, we will never get it done, and new
features will never be written.  Instead of focusing on these
discussions - which stop me from doing any fvwm work for one to
two months every time - how about doing some work towards the
release together instead?

Ciao

Dominik ^_^  ^_^

---

From: Uwe Pross <[email-masked]>
Date: Mon, 19 Jan 2004 10:01:54 +0100

Hi there,

On 17 Jan 2004 at 00:36:43 +0100, Olivier Chapuis wrote:

> If you use my version of FVWM you never get these beeps
> (and the function will be executed). But, for some reasons
> dominik does not want that your setup work. The last
> thread on this subject start here:
> 

Yes, it describes the same I meant.

> on the fvwm workers list (there was an other thread on
> this subject during the summer). I attach a patch (small)
> against the current cvs which always execute totally
> immediate function.

I have been running 2.5.7. at work for a while and want to
stay at this version since other users use this installation
as well - So I don't want to change for compatibility
reasons.

> I do not understand what you want to do with your
> FvwmEvent, but you can apply the patch and see if it
> causes problem (when you use your transient FvwmWinList or
> FrameMaker).

I use FvwmEvent to "remember" the focused window on the
current page. For the focused window FvwmEvent sets
windowstate 2. When I move to another page, move the pointer
and come back to a page I was before the last focused window
gets the focus again.

Since this does not work for all cases. I am not to unhappy
if I have to disable this function.

However, since this seems to be a general problem and you
have a solution to it, it should be considered to apply
this patch to avoid this problems in later versions.

Cheers, Uwe

---

From: Olivier Chapuis <[email-masked]>
Date: Mon, 19 Jan 2004 10:34:54 +0100

On Mon, Jan 19, 2004 at 10:00:16AM +0100, Dominik Vogt wrote:
> understand why you have to provoke this argument again.

I do not understand your position on the subject!
Note that I am not alone. Simply re-read the last thread
on the subject.
 
>  And it's
> discussions 

>- which stop me from doing any fvwm work for one to
> two months every time - 

It seems the same happen to me ...

> how about doing some work towards the

How can I work on FVWM as I *cannot* use the current cvs? Your are the
FVWM maintainer, one of the main developer (really I worked a lot on
the 2.5.x series) strongly think that we should do something about a
given subject. But you do not care and you reject any compromise. For
me there is a problem here.
 
Regards, Olivier