Subject: Re: Bug: Window move with mouse not working!

From: Arvind <[email-masked]>
Date: Sun, 13 Oct 2002 16:01:24 +0530

On Sun, Oct 12, Dominik Vogt, wrote:

> I can't reproduce it myself, but it doesn't surprise me.  I have
> rewritten the focus code recently and that probably plays a role
> here.

I'm not sure about that. It was happening a month back, too.
(Sorry, I know I'm expected to send a bug report early, but I was
trying to be sure if it was a bug.)

> Please describe the behaviour as precisely as you can:
> 
>  * Just to make sure:  did you actually try it with the minimal
>    config you posted?

Yes, I did, with exactly the same config. It still does the same
in today's CVS checked out version too.

>  * What exactly do you have to do to make it happen:
>    - Where do you press the mouse button?  Over the interior of
>      the window or on some part of the decorations (which part)?
>    - Where exactly do you move the windows?

1. I setup the config as I said.

2. I start fvwm. The builtin menu is got by right-clicking on the
   blank desktop. I select the first item, "1. XTerm".

3. I get the wire frame thing which allows me to place the window
   wherever I want to. I place it near the bottom of the screen.
   I move the window by pressing Alt and dragging the mouse
   *inside* the window. The window moves.

4. I do step 3 all over again, but, place the new terminal a
   little near the top of the screen such that the old one is
   partly visible.

5. Now, the new window can be moved by Alt + dragging inside the
   window, but, the old one can't.

>  * What is the "blinking" effect you see:
>    - Is the wire frame drawn for a split second and removed
>      immediately?
>    - Is the lower window raised and then lowered?
>    - Or is it a different effect (please describe)?
>
>  * Do you see the move cursor?  If not, does the cursor change to
>    some other icon (which)?

I did check the "blinking" effect and it is the visual bell of
the terminal. Somehow, instead of the mouse action being
interpreted by fvwm, it's being _sent to the terminal directly_.
I set the terminal bell in xterm to an audible one and it does
beep.

No, I don't see the wire-frame nor the move cursor. The lower
window doesn't seem to be raised and lowered. Maybe it's too fast
for the eyes, but I don't think so.

>  * Please add any additional information that seems unusual, even
>    it may seem unrelated.

Ok, here's an experiment I tried. After I had the two windows,
I closed the top one and the lower one still could not me moved.
It just beeped.

Here's another minimal config which is interesting:
--- 8< ---
Mouse 1             W    M Raise
Key F2              W    M Raise
--- 8< ---

If I have two windows, the clicking on the lower window with Alt
pressed down doesn't raise the window, but, Alt+F2 raises the
window if it's focused.

So, my description of my problem is: As soon as a window goes
into the background for the first time, somehow instead of fvwm
interpreting mouse actions, it's being sent directly to the app.

Ready to give you anymore info. Mail me. If it'd be easier for
you if I were on the list, tell me. Also, if none of the Fvwm
Workers can reproduce this problem, I'll assume it's a problem on
this side. Tell me if it's so.

But, I'm pretty sure it's not a problem at this end. I even
verified this with two different versions of the X server.

Arvind
-- 
It isn't easy being the parent of a six-year-old.  However, it's
a pretty small price to pay for having somebody around the house
who understands computers.
--
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: Mon, 14 Oct 2002 11:18:56 +0200

> On Sun, Oct 12, Dominik Vogt, wrote:

[snip]

> Here's another minimal config which is interesting:

That's because the code handling keystrokes works totally
differently than the code handling mouse buttons.

> interpreting mouse actions, it's being sent directly to the app.

That probably means that fvwm doesn't ask to be informed of these
button presses.  Please apply the attached patch to your code with

  $ cd fvwm/fvwm
  $ patch < debug.patch

recompile, record the output on the console it produces and
describe what exactly you did when you got which parts of the
output.  You can also fetch the latest CVS code instead of
patching, it contains the same debug code.

Bye

Dominik ^_^  ^_^

 --
Dominik Vogt, mail: [email-masked], phone: 0721/91374-382
Schlund + Partner AG, Erbprinzenstr. 4-12, D-76133 Karlsruhe
*** focus.c.orig	Mon Oct 14 11:02:51 2002
--- focus.c	Mon Oct 14 11:02:07 2002
***************
*** 864,869 ****
--- 864,870 ----
  	if (grab_buttons != fw->grabbed_buttons)
  	{
  		MyXGrabServer(dpy);
+ fprintf(stderr,"_fgb: grab 0x%x on 0x%08x '%s'\n", grab_buttons, (int)fw, fw->visible_name);
  		for (i = 0; i < NUMBER_OF_MOUSE_BUTTONS; i++)
  		{
  			__focus_grab_one_button(fw, i, grab_buttons);
*** events.c.orig	Mon Oct 14 11:12:53 2002
--- events.c	Mon Oct 14 11:12:12 2002
***************
*** 638,649 ****
--- 638,651 ----
  	PressedW = exc->w.w;
  	/* Now handle click to focus and click to raise. */
  	__handle_focus_raise_click(&f, exc);
+ fprintf(stderr,"_hbpom: do_focus: %d, do_raise: %d do_swallow: %d on 0x%08x '%s'\n", f.do_focus, f.do_raise, f.do_swallow_click, (int)exc->w.fw, exc->w.fw->visible_name);
  	if (f.do_focus)
  	{
  		if (!__handle_click_to_focus(exc))
  		{
  			/* Window didn't accept the focus; pass the click to the
  			 * application. */
+ fprintf(stderr,"  pass click 1\n");
  			f.do_swallow_click = 0;
  		}
  	}
***************
*** 651,656 ****
--- 653,659 ----
  	{
  		if (__handle_click_to_raise(exc) == True)
  		{
+ fprintf(stderr,"  delay raise\n");
  			/* We can't raise the window immediately because the
  			 * action bound to the click might be "Lower" or
  			 * "RaiseLower". So mark the window as scheduled to be
***************
*** 662,667 ****
--- 665,671 ----
  	/* handle bindings */
  	if (!f.do_forbid_function)
  	{
+ fprintf(stderr,"  function allowed\n");
  		/* stroke bindings */
  		__handle_bpress_stroke();
  		/* mouse bindings */
***************
*** 669,674 ****
--- 673,679 ----
  			Scr.AllBindings, STROKE_ARG(0) e->xbutton.button,
  			e->xbutton.state, GetUnusedModifiers(), exc->w.wcontext,
  			MOUSE_BINDING);
+ fprintf(stderr,"  action '%s'\n", action?action:"(null)");
  		if (__handle_bpress_action(exc, action))
  		{
  			f.do_swallow_click = 1;
***************
*** 688,693 ****
--- 693,699 ----
  	/* clean up */
  	if (!f.do_swallow_click)
  	{
+ fprintf(stderr,"  passing click\n");
  		/* pass the click to the application */
  		XAllowEvents(dpy, ReplayPointer, CurrentTime);
  		XFlush(dpy);
***************
*** 713,718 ****
--- 719,725 ----
  	}
  	else if (ea->exc->w.fw != NULL)
  	{
+ fprintf(stderr,"hbp: got bpress on 0x%08x '%s'\n", (int)ea->exc->w.fw, ea->exc->w.fw->visible_name);
  		__handle_bpress_on_managed(ea->exc);
  	}
  	else

---

From: Dominik Vogt <[email-masked]>
Date: Mon, 14 Oct 2002 11:31:53 +0200

>    window, but, the old one can't.

Update:  With these instructions I can reproduce the problem.
Don't bother applying the patch or sending me debug output.

Bye

Dominik ^_^  ^_^

---

From: Dominik Vogt <[email-masked]>
Date: Mon, 14 Oct 2002 13:20:24 +0200

> Here's another minimal config which is interesting:

Okay, fixed in CVS.  Depending on your configuration you may have
to add the line

  style * FPAllowRaiseClickFunction, FPAllowFocusClickFunction

to your config file.

Bye

Dominik ^_^  ^_^

---

From: Arvind <[email-masked]>
Date: Tue, 15 Oct 2002 20:20:08 +0530

>>>>>>>>>>>>>>>>> Original Message <<<<<<<<<<<<<<<<<<
> 

Great! Works wonders. Thanks. This is why I love open source ...

Also, one more thing before I go, a line like the one below
still conflicts with mouse action even after this patch:

Mouse 1  R    N

This might be needed if you use the stroke library. But, it's not
a big problem. I removed it and everything works fine. I don't
think you should worry about it.

Thanks very much,
Arvind
-- 
Did you hear that two rabbits escaped from the zoo and so far they have
only recaptured 116 of them?
--
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: Tue, 15 Oct 2002 17:20:44 +0200

> think you should worry about it.

What exactly is the problem?

Bye

Dominik ^_^  ^_^