Re: Bug in CVS Emacs frame positioning under X

[Fran Litterio]

On 3/25/06, Richard Stallman wrote:

>     The symptom is that not all of the frames end up positioned at x/y
>     coordinates 300/300.  Some frames are positioned at 300+A/300+B, where
>     A is the width of the left border drawn by the window manager and B is
>     the height of the top border drawn by the window manager.  Some frames
>     even end up at 400/400 !

> This resembles a problem that I struggled with about 10 years ago.
> It might be the same one.
>
> I found that various cases of window positioning were a little bit
> off.  So I would fix the case that failed, and then some other case
> started to fail.  Eventually I gave up.

My major concern is that the current malfunction has non-deterministic
user-visible effects.  Depending of the X event timing, programmatically
positioned frames can end up in one of three places:

        1. The correct position.

        2. Nearby the correct position (i.e., off by the width and height of the
           window manager decorations).

        3. Very far away from the correct position (i.e., off by hundreds of
           pixels in both the X and Y coordinates).

In cases #2 and #3, the difference between the incorrect position and the
correct position is remembered by the frame and affects all future positioning
of that frame.  In case #3, this can position a frame off-screen even if the
user specifies coordinates that are on-screen!

> With better records, perhaps I could have determined the pattern of
> what failed and what succeeded, and figured out an overall solution.
> We should start keeping such records now, in case the patch
> which fixes this case breaks another case.

The current algorithm in src/xterm.c is close to providing a universal solution,
but it makes one incorrect assumption: that the location of a frame after
calling XMoveWindow() is correctly specified in the first ConfigureNotify event
received after the call to XMoveWindow().  Function x_check_expected_move() uses
the location from the ConfigureNotify event to compensate for frames that are
mispositioned by "type A" window managers.

If there were a function that can be called to synchronously obtain the current
position of a window, then x_check_expected_move() could use that function
instead of relying on possibly incorrect data from the last ConfigureNotify
event.

I don't (yet) know enough about X Window system programming to know if such a
function exists.  If someone does know, please inform me.  If I find a solution,
I'll submit a patch.
--
Francis Litterio
address@hidden
http://world.std.com/~franl/
GPG and PGP public keys available on keyservers.