Debian Bug report logs - #20444
fvwm2 moves windows when it is restarted

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Laurent Bonnaud <bonnaud@irisa.fr>

To: submit@bugs.debian.org

Subject: fvwm2 moves windows when it is restarted

Date: 30 Mar 1998 20:04:34 +0200

 Package: fvwm2
 Version: 2.0.46-BETA-2

Hi,

to reproduce this small buglet, you need to setup at least 4 virtual
screens (it also 'works' with more) :

 AB
 CD

Now put a window in the upper-left corner of screen D (better done with
'EdgeResistance').  Then restart fvwm2.  You should notice that the
window has been translated one or two pixels up and left, and that a
part of its decoration is visible in screens B and C.

-- 
Laurent.

Message #12 received at 20444@bugs.debian.org (full text, mbox, reply):

From: Austin Donnelly <austin@greenend.org.uk>

To: Laurent Bonnaud <bonnaud@irisa.fr>

Cc: 20444@bugs.debian.org

Subject: Re: Bug#20444: fvwm2 moves windows when it is restarted

Date: Sun, 19 Apr 1998 21:25:02 +0100 (BST)

On , 30 Mar 1998, Laurent Bonnaud wrote:

>  Package: fvwm2
>  Version: 2.0.46-BETA-2

Again, this bug report was mis-filed the first time - sorry about the
delay.

> to reproduce this small buglet, you need to setup at least 4 virtual
> screens (it also 'works' with more) :
> 
>  AB
>  CD
> 
> Now put a window in the upper-left corner of screen D (better done with
> 'EdgeResistance').  Then restart fvwm2.  You should notice that the
> window has been translated one or two pixels up and left, and that a
> part of its decoration is visible in screens B and C.

I can't reproduce this using xconsole - which window do you use to
demonstrate this?  Are you using FvwmWinList, by any chance?

This sounds a little like a known problem with FvwmWinList, already
reported as Bug#16143. See the bug database for the full details.

Is you problem similar to this?

Austin

Message #17 received at 20444@bugs.debian.org (full text, mbox, reply):

From: Laurent Bonnaud <bonnaud@irisa.fr>

To: Austin Donnelly <austin@greenend.org.uk>

Cc: 20444@bugs.debian.org

Subject: Re: Bug#20444: fvwm2 moves windows when it is restarted

Date: 20 Apr 1998 15:25:28 +0200

>>>>> "Austin" == Austin Donnelly <austin@greenend.org.uk> writes:
Austin> 
Austin> I can't reproduce this using xconsole - which window do you use to
Austin> demonstrate this? 

It "works" with xterm or Emacs.

Austin> Are you using FvwmWinList, by any chance?

No.

Austin> This sounds a little like a known problem with FvwmWinList, already
Austin> reported as Bug#16143. See the bug database for the full details.
Austin> 
Austin> Is you problem similar to this?

The common point is the drift one pixel up and one pixel left but
that's all.  The differences are :

 - I'm not using FvwmWinList.
 - This happens when i restart fvwm2, not when i add a window to
   FvwmWinList.

-- 
Laurent.

Message #22 received at 20444@bugs.debian.org (full text, mbox, reply):

From: Charles Briscoe-Smith <cpbs@debian.org>

To: austin@greenend.org.uk

Cc: 20444@bugs.debian.org

Subject: Re: Bug#20444: fvwm2 moves windows when it is restarted

Date: Wed, 22 Apr 1998 23:17:13 +0100

In article <m0yR0e6-000w4fC@valour.greenend.org.uk> you write:
>On , 30 Mar 1998, Laurent Bonnaud wrote:
>
>I can't reproduce this using xconsole - which window do you use to
>demonstrate this?  Are you using FvwmWinList, by any chance?
>
>This sounds a little like a known problem with FvwmWinList, already
>reported as Bug#16143. See the bug database for the full details.

I think this is the same bug I've been meaning to report for some time.
Whenever I restart fvwm2, all the windows started since I last restarted
fvwm2 are offset by a fixed amount up and left.  For some windows,
the fixed amount is 0.

For xclock, xload and xbiff, it's 0.  For xconsole, it's also 0.
For xvt and xterm, it's 1.  For rocks-n-diamonds, it's 4.  For xeyes
and xcpustate, it's 1.

Open a new xterm, and move it to "+0 +0".  Restart fvwm2.  Click and
hold the left button on the title bar, and the position indicator reads
"-1 -1".  Move the xterm to "+0 +0" again.  Now start another xterm and
position it just to the right of the first ("+494 +0" on my system).
Now restart fvwm2 again.  Notice that the first xterm is at "+0 +0" as
it should be, but the second has moves up and left by a pixel.  If you
look carefully after the first incarnation of fvwm2 disappears and before
the new one starts, you can see that the two xterm windows are not lined
up properly.  I therefore suspect that the bug is in fvwm2's code which
deals with the save set.

Results of some experiments:

An xvt started with "xvt -geometry 60x20" exhibits this problem, but one
started with "xvt -geometry 60x20+0+0" does not, even though both appear
at the same location on the screen.

An xvt started with "xvt -bw 0" does not exhibit the problem.  "xvt -bw
1" behaves as described above (offset 1).  "xvt -bw 10" moves up and to
the left by 10 pixels.  I therefore believe that this is a error in the
calculation of the save set, where the window's border width has either
been forgotten, or taken into account where it shouldn't have been.

I think there was a similar bug filed against twm in xbase.  fvwm2 might
have inherited this one...

Cheers,

-- 
Charles Briscoe-Smith
White pages entry, with PGP key: <URL:http://alethea.ukc.ac.uk/wp?95cpb4>
PGP public keyprint: 74 68 AB 2E 1C 60 22 94  B8 21 2D 01 DE 66 13 E2

Send a report that this bug log contains spam.