[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Bug in CVS Emacs frame positioning under X
From: |
Francis Litterio |
Subject: |
Bug in CVS Emacs frame positioning under X |
Date: |
Wed, 22 Mar 2006 03:33:25 +0000 (UTC) |
User-agent: |
Loom/3.14 (http://gmane.org/) |
In the latest CVS Emacs under X, there seems to be a frame positioning bug that
is timing related. It doesn't happen deterministically, and I'm still trying to
create a test case that reproduces the problem. However, I added some printf()s
to the code in src/xterm.c, and I've seen the following things happen in this
order:
0. Assume a frame is positioned at x/y location 50/50.
1. The user executes a command that positions the frame by doing something like
this:
(set-frame-position theframe 200 200)
2. In src/xterm.c, x_set_offset() is called.
3. x_set_offset() calls XMoveWindow(..., 200, 200).
4. Next, x_set_offset() sees that f->wm_type == X_WMTYPE_UNKNOWN, so it sets
f->check_expected_move to 1 and stores 200 in f->expected_top and stores 200
in f->expected_left. It then returns.
5. Emacs receives a ConfigureNotify event from X, which causes
handle_one_event() to be called.
6. handle_one_event() calls x_real_positions() to obtain the current real
x/y location of the frame. It stores the x offset in f->left_pos and
the y offset in f->top_pos. Here is the bug: In some cases, the current
real x/y location of the frame is 50/50 (i.e., it appears to have not moved
yet) and in some cases it is 200/200 (i.e., it appears to have moved
already).
7. handle_one_event() calls x_check_expected_move(), which determines whether
the window manager is type A or type B. The difference between type A and B
window managers is that when positioning a frame to x/y location 0/0, type A
window managers will put the window decorations at least partly off-screen,
and type B window managers will not.
8. x_check_expected_move() compares f->expected_top to f->top_pos and
f->expected_left to f->left_pos. When f->top_pos is 50 (which it is _some_
of the time) and f->expected_top is 200, then x_check_expected_move() sets
f->wm_type to X_WMTYPE_A and sets f->move_offset_top to 150 = 200 - 50.
Similarly for the
From that moment on, all attempts to set the top offset of that frame causes
150 to be added to the user-supplied top offset! The same applies for the
frame's left offset.
When I create a reproduceable test case, I'll send it, but I'm hoping this
description of the problem is enough to perhaps help someone get to the
bottom of the problem.
--
Francis Litterio
flitterio@gmail.com
- Bug in CVS Emacs frame positioning under X,
Francis Litterio <=
- Message not available
- Message not available
- Re: Bug in CVS Emacs frame positioning under X, Fran Litterio, 2006/03/22
- Re: Bug in CVS Emacs frame positioning under X, Richard Stallman, 2006/03/25
- Re: Bug in CVS Emacs frame positioning under X, Jan Djärv, 2006/03/27
- Re: Bug in CVS Emacs frame positioning under X, Fran Litterio, 2006/03/28
- Re: Bug in CVS Emacs frame positioning under X, Jan Djärv, 2006/03/28
- Re: Bug in CVS Emacs frame positioning under X, Richard Stallman, 2006/03/29