On Tue, Mar 03, 2009 at 09:41:58AM +0100, Dominik Vogt wrote:
> On Sun, Mar 01, 2009 at 04:08:57PM -0600, David Fries wrote:
> > history and bug report:
> > I just upgraded fvwm and saw an edge bump behavior at the outside
> > paging border when moving a window.  When a window was moved into the
> > panning window the poiner and window would be bumped so the pointer
> > was moved outside the panning window.  This jumping was annoying and
> > was causing me to drop windows a pixel or two from the border, which I
> > would have to pickup and move again.
> 
> I don't understand the problem exactly.  Can you give me precise
> instructions with a minimal config file?

Just ConfigFvwmDefaults,
touch /tmp/empty
./fvwm -c /tmp/empty
left click background for menu, click Issue fvwm commands,
`OpaqueMoveSize 200`    (optional)
`Move`
Click and drag from the lower part of the window, and drag it to the
top of the screen.  Keep pushing up and you'll see the pointer and
window jitter as it jumps between the top pixel of the screen and two
pixels down.

> > This edge bump was introduced in 2.5.24 in virtual.c
> > revision 1.187
> > date: 2007/09/11 18:48:57;  author: domivogt;  state: Exp;  lines: +7 -7
> > * Fixed jumping windows under some circumstances when releasing the button 
> > in
> > interactive motion while hitting the desktop's edge.
> 
> I don't remember that exactly, but I still see a problem when I
> start moving windows with the keyboard.  Windows sometimes move a
> pixel away from the right or bottom border of the page.  My xemacs
> window is affected, but not my shells.

I was only using the mouse to move the window, but now that I play
around with the keyboad, it looks like it will do what you are
describing for the xemacs when the pointer hits the outside border.
That's because even though it didn't page to a different screen the
XWarpPointer caused the pointer to move which moved the window back.
I can't say why the shells (or any other window) would do anything
differently.

Wild, with the patch XWarpPointer isn't called, and the window keeps
going beyond the screen, and going, and going, and around 65535 it
will wrap around, and then there is some interesting behavior with
focus follows mouse failing to give focus to the window.  I find this
amusing, I don't think this wrap around is worth fixing.

> > That change moved the check for if the window was paged to be too
> > early, in my debugging it is never hit.  I moved it to right before xl
> > and yt are adjusted to be inside the panning windows.  Otherwise xl
> > and yt are updated, but the pointer isn't moved.  The real problem for
> > the jumping windows is in __move_loop.  In HandlePaging xl and yt are
> > pointer locations and __move_loop treats them as window locations.
> > __move_loop would only transform the result if HandlePaging would
> > return 1 meaning that the desktop was paged (which in the above commit
> > disable the non-paging return).
> > 
> > At least in my tests the 'Fake and event to force window reposition.'
> > in __move_loop isn't required, maybe it was just masking the
> > pointer to window location problem.  I left it inside #if 0 for
> > someone else to look at.

-- 
David Fries <[email protected]>
http://fries.net/~david/ (PGP encryption key available)

Reply via email to