emacs-devel
[Top][All Lists]
Advanced

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

Re: address@hidden: [21.2.90]: Lesstif menu placement after frame resize


From: Jan D.
Subject: Re: address@hidden: [21.2.90]: Lesstif menu placement after frame resize]
Date: Sun, 6 Oct 2002 02:04:07 +0200 (CEST)

> 
> "Jan D." <address@hidden> writes:
> 
> > Yes, this only happens with CDE to my knowledge.  It is because a
> > workaround for bad ConfigureNotify events that doesn't take into
> > account position changes because of resize.  This bug is at least as
> > old as Emacs 21.1 (the oldest I got), but could be older.
> 
> UUps, it's not only the CDE environment. I got the problem too with
> windowmaker then I resize the Window with 'Mod + Mouse 3' inside the
> emacs window. I debugged into your fix and in the special case
> windowmaker set not for both event.xconfigure.x and event.xconfigure.y
> a zero value.

Good, now we can test this without CDE.

The coordinates 22 0 are in fact the size of the window decorations that
WindowMaker sets up (well more or less).

I reread ICCCM and poked around in the Xt sources, and here
how it works.

There are "real" ConfigureNotify events that happen when you resize a
window, and then there are syntetic ConfigureNotify events from the
window manager when a window gets moved.  The syntetic ones always
have the correct x/y, i.e. relative to the root window.
The "real" ones from the X Server does not.  Their x/y are relative to
the parent of the window, which is not root if a window manager is running.
The window manager puts another window as parent (to put in the window
manager decorations).  You can verify this by getting the menus in
the erronous position, and then move the Emacs window just a bit.  Menus
then snap back to the correct position.

The Xt shell widget first assumes no window manager is running, so all
ConfigureNotify events are considered when it saves x/y.  But if
it gets a ReparentNotify, it knows that a window manager is running and
after that, only x/y in syntetic events are considered.

The bug in Emacs was that ReparentNotify was never passed to Xt, so
the shell widget kept looking at all ConfigureNotify events.

The fix is really simple, send ReparentNotify to Xt and we can get rid
of the workaround code.

I have checked in this in CVS and verified it on Windowmaker.  If you
can verify it on CDE it would be great.  I will check CDE also, but I
can't do that until later next week.

        Jan D.





reply via email to

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