emacs-devel
[Top][All Lists]
Advanced

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

Frame positioning bug in src/xterm.c


From: Francis Litterio
Subject: Frame positioning bug in src/xterm.c
Date: Fri, 24 Mar 2006 17:20:43 +0000 (UTC)
User-agent: Loom/3.14 (http://gmane.org/)

The code in src/xterm.c has a frame-positioning bug under the X Window system.
To reproduce the bug, do this:

  1. Start Emacs under the X Window system using the command:

        emacs -q

  2. Evaluate the following Elisp:

        (dolist (i '(1 2 3 4 5 6 7 8 9 a b c))
          (let ((frame (make-frame '((top . 50) (left . 50)))))
            (set-frame-position frame 200 200)
            (set-frame-position frame 300 300)
            (sit-for 0.5)))

You may have to evaluate the above Elisp more than once to see the bug (although
I see it every time).

The symptom of the bug is that not all of the new frames end up at x/y location
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!

I think the cause of this problem is the fact that src/xterm.c assumes
(incorrectly) that after calling XMoveWindow() to set a new position for a
frame, the next ConfigureNotify event received for that frame will contain the
new position of the frame.  In fact, the next ConfigureNotify event sometimes
contains the current position of the frame (i.e., the position from before
the call to XMoveWindow()).

Function x_check_expected_move() attempts to use the position data from the most
recently received ConfigureNotify to compensate for so-called "type A" window
managers, which add a constant x/y offset to every repositioned window.  But the
above incorrect assumption causes x_check_expected_move() to fail to compensate
or to _over_ compensate for the behavior of the window manager.

I'm not sure how to fix this.  Perhaps the ConfigureNotify event is received
before the call to XMoveWindow() but processed after the call to XMoveWindow().
If so, then it may be possible to ignore the ConfigureNotify events that have
out-of-date position information, but I don't know enough about X events to
determine when an event was generated.

If I come up with a fix, I'll post the patch.
--
Fran Litterio






reply via email to

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