* Bug in CVS Emacs frame positioning under X
@ 2006-03-22 3:33 Francis Litterio
[not found] ` <E1FM3do-0006e6-It@fencepost.gnu.org>
0 siblings, 1 reply; 7+ messages in thread
From: Francis Litterio @ 2006-03-22 3:33 UTC (permalink / raw
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Bug in CVS Emacs frame positioning under X
[not found] ` <a5b589a70603220556y2865a5f1n82bfef5863d68da5@mail.gmail.com>
@ 2006-03-22 21:02 ` Fran Litterio
2006-03-26 0:21 ` Richard Stallman
0 siblings, 1 reply; 7+ messages in thread
From: Fran Litterio @ 2006-03-22 21:02 UTC (permalink / raw
Cc: bug-gnu-emacs, emacs-devel
On 3/22/06, I (Fran Litterio) wrote:
> On 3/22/06, Richard Stallman wrote:
> > In the latest CVS Emacs under X, there seems to be a frame positioning bug that
> > is timing related.
> >
> > Does it happen in older CVS versions too? For instance,
> > did it happen a month ago? 6 months ago?
>
> Unknown. I'll check-out the older sources and rebuild. I'll let you know.
I have checked out the CVS Emacs source code from October 1, 2005, and
the bug existed at that time. Additionally, I have found a simple way
to reproduce the problem:
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))
(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
malfunction (although I see it every time).
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 !
I think I have a patch to src/xterm.c that may fix this. I will try
it and let you know if the patch works.
--
Fran Litterio
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Bug in CVS Emacs frame positioning under X
2006-03-22 21:02 ` Fran Litterio
@ 2006-03-26 0:21 ` Richard Stallman
2006-03-27 6:48 ` Jan Djärv
2006-03-28 16:38 ` Fran Litterio
0 siblings, 2 replies; 7+ messages in thread
From: Richard Stallman @ 2006-03-26 0:21 UTC (permalink / raw
Cc: bug-gnu-emacs, emacs-devel
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 !
I think I have a patch to src/xterm.c that may fix this. I will try
it and let you know if the patch works.
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.
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.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Bug in CVS Emacs frame positioning under X
2006-03-26 0:21 ` Richard Stallman
@ 2006-03-27 6:48 ` Jan Djärv
2006-03-28 16:38 ` Fran Litterio
1 sibling, 0 replies; 7+ messages in thread
From: Jan Djärv @ 2006-03-27 6:48 UTC (permalink / raw
Cc: bug-gnu-emacs, Fran Litterio, emacs-devel
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 !
>
> I think I have a patch to src/xterm.c that may fix this. I will try
> it and let you know if the patch works.
Please also tell which window managers you tested it on.
>
> 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.
That is the basic problem. Each window manager does window moves differently,
and the fact that events may come at different times complicates things. I
now try to make it work on a lot of window managers, but I gave up on "all".
>
> 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 patch must be tested on at least 10 or so of the most common window
managers. Usually it is difficult to make a patch that doesn't break some
other window manager.
Jan D.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Bug in CVS Emacs frame positioning under X
2006-03-26 0:21 ` Richard Stallman
2006-03-27 6:48 ` Jan Djärv
@ 2006-03-28 16:38 ` Fran Litterio
2006-03-28 16:59 ` Jan Djärv
2006-03-29 23:01 ` Richard Stallman
1 sibling, 2 replies; 7+ messages in thread
From: Fran Litterio @ 2006-03-28 16:38 UTC (permalink / raw
Cc: bug-gnu-emacs, emacs-devel
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
flitterio@gmail.com
http://world.std.com/~franl/
GPG and PGP public keys available on keyservers.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Bug in CVS Emacs frame positioning under X
2006-03-28 16:38 ` Fran Litterio
@ 2006-03-28 16:59 ` Jan Djärv
2006-03-29 23:01 ` Richard Stallman
1 sibling, 0 replies; 7+ messages in thread
From: Jan Djärv @ 2006-03-28 16:59 UTC (permalink / raw
Cc: bug-gnu-emacs, Richard Stallman, emacs-devel
Fran Litterio wrote:
>
> 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.
XSync, XMoveWindow, and then XSync again should make the next ConfigureWindow
contain the position after move. XGetGeometry and XGetWindowAttributes should
do the trick.
Jan D.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Bug in CVS Emacs frame positioning under X
2006-03-28 16:38 ` Fran Litterio
2006-03-28 16:59 ` Jan Djärv
@ 2006-03-29 23:01 ` Richard Stallman
1 sibling, 0 replies; 7+ messages in thread
From: Richard Stallman @ 2006-03-29 23:01 UTC (permalink / raw
Cc: bug-gnu-emacs, emacs-devel
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:
It could be that we could solve this by completely reorganizing the
way that code works. The person who wrote it was not the best
programmer, and I then tried to fix it up with just a partial
understanding of how to use Xt. Someone who really knows the right
way to use Xt could perhaps do this right, and then it would work.
Let's continue this discussion just on emacs-devel.
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2006-03-29 23:01 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2006-03-22 3:33 Bug in CVS Emacs frame positioning under X Francis Litterio
[not found] ` <E1FM3do-0006e6-It@fencepost.gnu.org>
[not found] ` <a5b589a70603220556y2865a5f1n82bfef5863d68da5@mail.gmail.com>
2006-03-22 21:02 ` Fran Litterio
2006-03-26 0:21 ` Richard Stallman
2006-03-27 6:48 ` Jan Djärv
2006-03-28 16:38 ` Fran Litterio
2006-03-28 16:59 ` Jan Djärv
2006-03-29 23:01 ` Richard Stallman
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).