Subject: Pager breakage - move.c rewrite suspected

From: Bob Woodside <[email-masked]>
Date: Thu, 5 Nov 1998 02:24:39 -0500 (EST)

Has anyone noticed that the Pager feature that allows you to
drag a window "out of the Pager" and onto the current desktop page is
broken? Instead, the window goes to some oddball location on another
page (but the correct desk).

	I think the problem is probably in the rewritten move code, and
therefore related to the breakage of ActivePlacement.

	While we're on the subject, OpaqueMove acts a bit strangely these
days. When I do an opaque move by dragging the titlebar, sometimes --
and I haven't toyed with enough to figure out the boundary condition --
the mouse cursor will suddenly jump some distance above the window and
change to the resizing cursor; it stays that way for the rest of the
move. Decidedly inelegant.

	Is anybody currently working on this stuff?

- Bob

--
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: Tim Phipps <[email-masked]>
Date: Thu, 05 Nov 1998 11:46:02 +0000

>         Is anybody currently working on this stuff?
Ooh err! I patched move.c to fix a problem with move invoked from a
menu.  In the past the move assumed that the pointer was on the menu
item that started the move.  This caused the window to jump at the start
of the move if the pointer was not on the menu item.  I can't find
anything wrong with moving from window decorations but I can reproduce
problems with moving from the pager.  I'll look into this but could you
try to to give an example of opaque moves going funny?

Has anyone else had the problem with moves from the pager causing extra
pagers to be started?  Every time I move a window in the pager with
button 2 another one starts up.  My pager is swallowed in FvwmButtons so
it could be a problem with either.  It doesn't happen with a standalone
Pager

Cheers,
Tim.

---

From: Bob Woodside <[email-masked]>
Date: Thu, 5 Nov 1998 07:51:31 -0500 (EST)

Tim Phipps <[email-masked]> wrote:

> I'll look into this but could you try to to give an example of opaque
> moves going funny?

	Ok, a little further investigation shows a timing problem. If I
slowly and deliberately press the mouse button, then wait for the cursor
to change to the move/resize cursor, then the behavior is normal. However,
if I'm moving quickly, the cursor stays wherever it was when the cursor
change caught up to it. It's not necessarily *above* the window, as I said
before, that's just the direction I was moving when I noticed the problem.
It might be to the side, or on a diagonal, or inside the client area of
the window.

	I was also mistaken about the opaque move aspect. The same thing
occurs with rubber band moves, it was just much more obvious with the
small opaque move windows I was shuffling around last night.

	I just brought up 2.0.46 for a quick comparison, and what it
appears to do in this case is to warp the cursor back to the position
from which you started moving, once the cursor change catches up with
your mouse movement.

- Bob

---

From: Brad Giaccio <[email-masked]>
Date: Thu, 5 Nov 1998 08:06:21 -0500 (EST)

> it could be a problem with either.  It doesn't happen with a standalone
This may sound silly but did you check to make sure you don't have a mouse
action setup in your Buttons config that is respawning the app. Otherwise
I don't see it happening to me and my Pager is also swallowed.  Just a
thought.

I can also confirm both of Bob's problems with the pager and with the move
window cursor problem.

Brad

-- 
--- There are two kinds of knowledge, you either know the answer or
			you know where to find it
		      -Kane, Johnson, and anonymous

---

From: Tim Phipps <[email-masked]>
Date: Fri, 06 Nov 1998 15:08:44 +0000

> I don't see it happening to me and my Pager is also swallowed.  Just a

The extra Pagers happen when I have swallow(respawn).  I'm guessing but
the extra pager happens when I release button 2 in a move from the
pager.  Moves in the pager cause a little window in the pager to be
created which follows the cursor. When I release button 2 this little
window is closed.  It might be that FvwmButtons gets the little window
closure event and assumes that it is the swallowed window going away and
so starts a new one.  Does this sound reasonable?

> I can also confirm both of Bob's problems with the pager and with the move

Me too, undo my patch to move.c until I fix it, the old behaviour is
more correct.  I was trying to fix a problem that is made worse with the
menu positioning code. i.e. I have a window and the pointer in the
middle of the screen.  With a key press I get a menu to pop up in the
bottom left of the screen and from that I start a move.  What happens is
that the move command gets the dragX, dragY numbers from the menu which
is in the bottom left so it keeps the window some distance to the upper
right of the pointer.   When you start moving the window zooms off to
the upper right and you can't get it out of the upper right quadrant.

What I need to do is enclose the Querypointer in a test of the event
type.

Cheers,
Tim.

---

From: Tim Phipps <[email-masked]>
Date: Mon, 09 Nov 1998 12:25:38 +0000

Hi All,
	Here's a patch to today's code (9th November) that I think fixes the
problem.  The QueryPointer is only done if the Xevent was a key press. 
This means moves from the pager and moves from window decorations acts
like before.
The problem with moves from key presses from menus is also fixed.

Let me know if this breaks anything,
Tim.

Index: move.c
===================================================================
RCS file: /home/cvs/fvwm/fvwm/fvwm/move.c,v
retrieving revision 1.11
diff -u -r1.11 move.c
--- move.c	1998/11/09 10:36:29	1.11
+++ move.c	1998/11/09 12:14:47
@@ -602,18 +602,15 @@
     }

-  DragX = eventp->xbutton.x_root;
-  DragY = eventp->xbutton.y_root;
-  /* If this is commented out, then the move starts from the button press
-   * location instead of the current location */
-/*  RBW-temp  - uncommenting this does 2 things:
-      - breaks moving a window "out of the Pager" onto the desktop (we
-        don't want the window in its current location, we want it *here*)
-      - causes the cursor to "lead" the move during normal grab-and-drag
-        operations
-  XQueryPointer(dpy, Scr.Root, &JunkRoot, &JunkChild,
-      &DragX, &DragY,	&JunkX, &JunkY, &JunkMask);
-*/
+  
+  if (eventp->type != KeyPress)
+    {
+      DragX = eventp->xbutton.x_root;
+      DragY = eventp->xbutton.y_root;
+    }
+  else
+     XQueryPointer(dpy, Scr.Root, &JunkRoot, &JunkChild, &DragX, &DragY,
+                   &JunkX, &JunkY, &JunkMask);
 
   if(!GrabEm(MOVE))
     {

---

From: [email-masked]
Date: Mon, 9 Nov 1998 15:10:32 +0100

I committed the bugfix.

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: Tim Phipps <[email-masked]>
Date: Thu, 12 Nov 1998 18:32:41 +0000

> so starts a new one.  Does this sound reasonable?

I've tracked this down a little bit further and what is happening is
that FvwmPager is mapping and unmapping a little window. FvwmButtons
gets the UnmapNotify event and assumes the window it swallowed has gone
away.  Attached is a small patch that disables this.  It will still
respawn if the window is destroyed.  I've tested it on my set up and it
works for me.  I'm a bit worried though that other apps that get
swallowed might be unmapping themselves and would not get respawned. I'm
not sure if respawning when a swallowed window unmaps is the right
thing, if the window is destroyed (by the app dying) then a respawn will
happen but if apps unmap themselves you would end up with lots.

A more complete fix would be to check that the window that got unmapped
is the directly swallowed one and not a child of the swallowed one.  I'm
not sure what FvwmPager is doing when it creates the moving window but
FvwmButtons gets a ReparentNotify when the moving window is created
followed by MapNotify when it appears, followed by ConfigureNotify's as
it moves. When you let go there is an UnmapNotify (which causes the
respawn).

Any ideas?
Tim.

---

From: Tim Phipps <[email-masked]>
Date: Fri, 13 Nov 1998 16:49:53 +0000

Silly me forgot to attach the patch.

Index: FvwmButtons.c
===================================================================
RCS file: /home/cvs/fvwm/fvwm/modules/FvwmButtons/FvwmButtons.c,v
retrieving revision 1.4
diff -r1.4 FvwmButtons.c
861c861
< 	  case UnmapNotify: /* Not really sure if this is abandon all hope.. */
---
> /*	  case UnmapNotify: /* Not really sure if this is abandon all hope.. */

---

From: Dominik Vogt <[email-masked]>
Date: Mon, 23 Nov 1998 15:19:32 +0100

> it moves. When you let go there is an UnmapNotify (which causes the

How is the status here? Don't think the patch is in, but I had
the impression it's only a temporary fix.

Dominik

---

From: Tim Phipps <[email-masked]>
Date: Mon, 23 Nov 1998 14:21:40 +0000

> the impression it's only a temporary fix.
The patch that comments out the handling of unmap notify events works
for me, I think you should commit it.

Cheers,
Tim.