[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Bug-XBoard] Xboard-4.5.3a bug: windows sliding

From: Byrial Jensen
Subject: Re: [Bug-XBoard] Xboard-4.5.3a bug: windows sliding
Date: Sat, 25 Feb 2012 10:52:41 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2


When I start Xboard and quit again the coordinates in .xbaordrc have changed for all windows, even if they were never opened.

Anyway a posible solution might be to not to change the stored positions in the configuration file unless the postion is changed more than some threshold value, so only manual movements of the windows are likely to be registered.

It might also be possible to read the positions both immediately after creation and when the windows are closed, and only change the configuration file if these two set of position values are different, indication a manual movement.

- Byrial

Den 25-02-2012 08:13, h.g. muller skrev:

Windows slide exactly 4 pixels to the left from session to session.
That is, open some windows so that there is a margin to the left on
the screen. Then quit, and start another session. Then all new windows
have moved exactly 4 pixels to the left relative to the position from
the previous session.

The problem is that the X-server lies to the application about the
positioning of the windows. When you request the position, and then on a
later popup position it the same way, it has moved quite a lot. It sems
this has to do with the width of the frame and title bar, added to it by
the windows manager: in one case they are counted, but not in the other.
So I tried to compensate by adding a constant to the coordinates to
account for the widths of the ornaments.

The problem is that the width might not be the same on every system. For
you it seems it is 4 pixels wider than what I actually add.

Another problem is that on my Ubuntu 8.04 it was not reproducible
either. Whatever constant I added, when I aligned them so they touched,
closing XBoard and restarting it would sometimes still have them touch,
but often create a 1-pixel gap or a 1-pixel overlap between the formerly
touching windows. So I kind of gave up on this, and never got to port
the -stickyWindows feature (which really attaches paramount importance
to whether windows exactly touch or not) from WinBoard to XBoard.

To alleviate the problem a bit, I could make the addition configrable,
rather than a hard constant. E.g. have -fudgeX and -fudgeY options, so
that in your case you could solve it by increasing the -fudgeX value by 4.

Bug-XBoard mailing list

reply via email to

[Prev in Thread] Current Thread [Next in Thread]