Subject: Fvwm 2.3.1 looses its grip

From: Dan Espen <[email-masked]>
Date: Thu, 15 Apr 1999 14:48:50 -0400

I first noticed this using today's CVS.  I can't reproduce it with
2.2.

If I grab the resize handle with the mouse, and move the pointer along
the top edge of the screen, fvwm can lose its grip on the rubber band.
The pointer  continues  to  be   the  resize pointer, but  it    moves
independently of the resize frame.

The top edge of the screen I'm on should not have a pan frame.

-- 
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: Dominik Vogt <[email-masked]>
Date: Fri, 16 Apr 1999 17:47:44 +0200

> The top edge of the screen I'm on should not have a pan frame.

Doesn't happen for me. How did you set up your window borders?

Bye

Dominik ^_^

--
Dominik Vogt, [email-masked]
Reply-To: [email-masked]
--
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: Fri, 16 Apr 1999 11:59:41 -0400

> Doesn't happen for me. How did you set up your window borders?

It takes some trying before it happens (its not real easy to create).

EdgeScroll 100 100
EdgeResistance 500 1
Style "*" BorderWidth 12, HandleWidth 12,MouseFocus

# -- Start of Custom Decor --
DestroyDecor    Custom
AddToDecor      Custom
+ TitleStyle Centered ActiveUp (Solid cornflowerblue -- Raised) \
             Inactive (Solid Navy -- Flat) \
             ActiveDown (Solid dimgrey -- Sunk)
+ ButtonStyle 1 Pixmap mini.iconify.xpm
+ ButtonStyle 3 MiniIcon
+ ButtonStyle 4 Pixmap mini.delete.xpm mini.destroy.xpm
+ ButtonStyle 2 Pixmap mini.maximize.xpm mini.resize.xpm
+ BorderStyle TiledPixmap weird10.xpm -- HiddenHandles NoInset
+ WindowFont 9x15bold
+ HilightColor   white cornflowerblue

DestroyFunc DecorCustom
AddToFunc   DecorCustom "I" MenuStyle "*"   WIN, PopupDelayed, PopupDelay 150
+ "I" MenuStyle "*" Foreground white, Background cornflowerblue, Greyed navy
+ "I" MenuStyle "*" Font 9x15bold, Animation, Hilight3DThin
+ "I" MenuStyle "*" ActiveFore yellow, HilightBack dimgrey
+ "I" MenuStyle "*" PopupOffset 1 100
+ "I" Style "*" UseDecor Custom, Color lightgray/dimgrey
+ "I" SetAnimation 1 .3 .6 1.0
+ "I" Recapture

DecorCustom

---

From: Matthias Clasen <[email-masked]>
Date: Fri, 16 Apr 1999 23:56:31 +0200

> The top edge of the screen I'm on should not have a pan frame.

I can reproduce this too. Grab the resize handle, move the pointer to
the top or left edge of page 0x0, wait for a second. If I then continue
to move the mouse, the resize frame doesn't follow any longer. This
doesn't happen at edges with pan frames.

Matthias

-- 
Matthias Clasen, 
Tel. 0761/203-5606
Email: [email-masked]
Mathematisches Institut, Albert-Ludwigs-Universitaet Freiburg
--
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: Matthias Clasen <[email-masked]>
Date: Sat, 17 Apr 1999 02:47:28 +0200

further diagnosis of the resize-on-edge problem: If I "loose" the rubberband
on an "inactive" edge of the screen and then move the cursor over an "active"
edge to switch to another page, the rubberband follows the mouse again.
Thus I think that fvwm forgets to update the rubberband until a HandlePaging
call returns true, but I haven't quite figured out where in InteractiveResize
that happens.

Matthias

---

From: Dominik Vogt <[email-masked]>
Date: Sat, 17 Apr 1999 14:19:24 +0200

> It takes some trying before it happens (its not real easy to create).

Not when you know what to do.

> EdgeResistance 500 1

These two lines are enough to show the bug. It happens whenever you
move the resize cursor to the edge of the desktop and leave it there
at least as long as you defined in the EdgeResisteance command. It
works on the other page boundaries.

Since it seems to be cause by the rewrite of the HandlePaging function
I did recently I'm looking into this.

------------- five minutes later -------------

Hah, that was easy to fix. I simply forgot to reset the
fForceRedraw flag in the resize function. Once it was set the
resize frame wasn't redrawn anymore.

Bye

Dominik ^_^

---

From: Matthias Clasen <[email-masked]>
Date: Sat, 17 Apr 1999 22:38:53 +0200

> resize frame wasn't redrawn anymore.

Interesting. You fix a bug caused by a rewrite of HandlePaging
by changing resize_window :-).

I independently found a different fix: I found that
the HandlePaging function will return true if you leave the pointer
on a pan frame for long enough, regardless if it actually did switch 
page to a different page or not. I changed this to return true only
if it actually switched pages, thereby fixing the ill behaviour of 
resize. 

I'll commit it, since I think it is correct and will be easy to
back out again (tell me if my conclusions about the return value
of HandlePaging are wrong).

Matthias

---

From: Dominik Vogt <[email-masked]>
Date: Sun, 18 Apr 1999 03:03:50 +0200

> by changing resize_window :-).

That's because the interface of HandlePaging changed and I had to
adapt resize and move. The bug was in resize_window, not in
HandlePaging.

> of HandlePaging are wrong).

Gack! I'll trust you. I don't want to look at the code again, it
gave me plenty of headaches. What you have done sounds right
(provided you did consider the case that the desktop may wrap around
when you're on the desktop edge). But in the end it doesn't fix
the bug in resize_window, it only hides the symptom.

Bye

Dominik ^_^

---

From: Matthias Clasen <[email-masked]>
Date: Sun, 18 Apr 1999 21:05:14 +0200

> the bug in resize_window, it only hides the symptom.

I just inserted a check immediately before actually doing the 
MoveViewport that delta_x and delta_y are nonzero. If they are zero,
MoveViewport doesn't change the page and we should return false.
I hope this catches all desktop wrapping, since it should be taken 
into account when calculating the deltas. 

Matthias