[simon.marshall@misys.com: [21.2.90]: Lesstif menu placement after frame resize]

[simon.marshall@misys.com: [21.2.90]: Lesstif menu placement after frame resize]

[Richard Stallman]

Are there any X wizards out there who might be able to
investigate this?

------- Start of forwarded message -------
Envelope-to: emacs-pretest-bug@gnu.org
Delivery-date: Thu, 19 Sep 2002 09:29:43 -0400
X-VirusChecked: Checked
From: "Marshall, Simon" <simon.marshall@misys.com>
To: 'Emacs Pretest Bug' <emacs-pretest-bug@gnu.org>
Subject: [21.2.90]: Lesstif menu placement after frame resize
Date: Thu, 19 Sep 2002 14:29:34 +0100
X-Spam-Status: No, hits=1.1 required=5.0
	tests=DOUBLE_CAPSWORD
	version=2.31
X-Spam-Level: *

In GNU Emacs 21.2.90.1 (sparc-sun-solaris2.6, GNU/LessTif Version 2.1
Release 0.93.36)
 of 2002-09-19 on perth
configured using `configure  --prefix=/rvcarma/marshals/slash/usr/local
- --x-includes=/usr/openwin/include:/rvcarma/marshals/slash/usr/local/incl
ude:/rvcarma/marshals/slash/usr/local/include/X11
- --x-libraries=/usr/openwin/lib:/rvcarma/marshals/slash/usr/local/lib:/rv
carma/marshals/slash/usr/local/lib/X11 --with-x-toolkit=motif'
Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: en_UK
  value of $LC_CTYPE: en_UK
  value of $LC_MESSAGES: C
  value of $LC_MONETARY: en_UK
  value of $LC_NUMERIC: en_UK
  value of $LC_TIME: en_UK
  value of $LANG: en_UK
  locale-coding-system: iso-latin-1
  default-enable-multibyte-characters: t

Please describe exactly what actions triggered the bug
and the precise symptoms of the bug:

I've seen this with earlier Emacs & earlier Lesstif versions, but I
thought I'd gripe about it now...

With the above build configuration, start emacs -q.
Open the Tools menu; it drops down below the Tools menu name.
The menu is top left aligned with the bottom left of the name.  OK.
Resize the frame (wider or smaller) from the left edge.
Open the Tools menu.

Now it drops down below where the Tools menu name used to be, not
where it is following the resize.

In case it's relevant, this is with Solaris CDE 1.2 via Exceed 6.2.
It applies to any of the menus, including Help.

Simon.

________________________________________________________________________
This e-mail has been scanned for all viruses by Star Internet. The
service is powered by MessageLabs. For more information on a proactive
anti-virus service working around the clock, around the globe, visit:
http://www.star.net.uk
________________________________________________________________________
------- End of forwarded message -------

Re: [simon.marshall@misys.com: [21.2.90]: Lesstif menu placement after frame resize]

[Harald.Maier.BW]

Richard Stallman <rms@gnu.org> writes:

> Are there any X wizards out there who might be able to
> investigate this?

No, I am not a wizard, but I noticed this too with the Solaris CDEs
(Solaris 2.6 and Solaris 8) and with a old GNU/Linux CDE. It seems
that this is specific to the CDE desktop.

Harald

> From: "Marshall, Simon" <simon.marshall@misys.com>
> Subject: [21.2.90]: Lesstif menu placement after frame resize
> To: 'Emacs Pretest Bug' <emacs-pretest-bug@gnu.org>
> Date: Thu, 19 Sep 2002 14:29:34 +0100
>
> In GNU Emacs 21.2.90.1 (sparc-sun-solaris2.6, GNU/LessTif Version 2.1
> Release 0.93.36)
>  of 2002-09-19 on perth
> configured using `configure  --prefix=/rvcarma/marshals/slash/usr/local
> - --x-includes=/usr/openwin/include:/rvcarma/marshals/slash/usr/local/incl
> ude:/rvcarma/marshals/slash/usr/local/include/X11
> - --x-libraries=/usr/openwin/lib:/rvcarma/marshals/slash/usr/local/lib:/rv
> carma/marshals/slash/usr/local/lib/X11 --with-x-toolkit=motif'
> Important settings:
>   value of $LC_ALL: nil
>   value of $LC_COLLATE: en_UK
>   value of $LC_CTYPE: en_UK
>   value of $LC_MESSAGES: C
>   value of $LC_MONETARY: en_UK
>   value of $LC_NUMERIC: en_UK
>   value of $LC_TIME: en_UK
>   value of $LANG: en_UK
>   locale-coding-system: iso-latin-1
>   default-enable-multibyte-characters: t
>
> Please describe exactly what actions triggered the bug
> and the precise symptoms of the bug:
>
> I've seen this with earlier Emacs & earlier Lesstif versions, but I
> thought I'd gripe about it now...
>
> With the above build configuration, start emacs -q.
> Open the Tools menu; it drops down below the Tools menu name.
> The menu is top left aligned with the bottom left of the name.  OK.
> Resize the frame (wider or smaller) from the left edge.
> Open the Tools menu.
>
> Now it drops down below where the Tools menu name used to be, not
> where it is following the resize.
>
> In case it's relevant, this is with Solaris CDE 1.2 via Exceed 6.2.
> It applies to any of the menus, including Help.

Re: [simon.marshall@misys.com: [21.2.90]: Lesstif menu placement after frame resize]

[Jan D.]

> Are there any X wizards out there who might be able to
> investigate this?
> 
> ------- Start of forwarded message -------
> Envelope-to: emacs-pretest-bug@gnu.org
> Delivery-date: Thu, 19 Sep 2002 09:29:43 -0400
> X-VirusChecked: Checked
> From: "Marshall, Simon" <simon.marshall@misys.com>
> To: 'Emacs Pretest Bug' <emacs-pretest-bug@gnu.org>
> Subject: [21.2.90]: Lesstif menu placement after frame resize
> Date: Thu, 19 Sep 2002 14:29:34 +0100
> X-Spam-Status: No, hits=1.1 required=5.0
> 	tests=DOUBLE_CAPSWORD
> 	version=2.31
> X-Spam-Level: *
> 
> With the above build configuration, start emacs -q.
> Open the Tools menu; it drops down below the Tools menu name.
> The menu is top left aligned with the bottom left of the name.  OK.
> Resize the frame (wider or smaller) from the left edge.
> Open the Tools menu.
> 
> Now it drops down below where the Tools menu name used to be, not
> where it is following the resize.
> 
> In case it's relevant, this is with Solaris CDE 1.2 via Exceed 6.2.
> It applies to any of the menus, including Help.

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.

I've checked in this fix in CVS.  Should it go in RC also?

	Jan D.

Index: xterm.c
*** xterm.c.~1.753.~	2002-10-03 19:25:46.000000000 +0200
--- xterm.c	2002-10-03 19:44:17.000000000 +0200
***************
*** 11179,11186 ****
  		     in the emacs widget, which messes up Motif menus.  */
  		  if (event.xconfigure.x == 0 && event.xconfigure.y == 0)
  		    {
! 		      event.xconfigure.x = f->output_data.x->widget->core.x;
! 		      event.xconfigure.y = f->output_data.x->widget->core.y;
  		    }
  #endif /* USE_MOTIF */
  		}
--- 11179,11202 ----
  		     in the emacs widget, which messes up Motif menus.  */
  		  if (event.xconfigure.x == 0 && event.xconfigure.y == 0)
  		    {
!                       Window child;
! 		      int count;
! 
! 		      /* We can get a ConfigureNotify because of a resize,
! 			 so we can't just take x and y from the widget.
! 			 Since this event may come on something else than
! 			 the top level window,  we can't use x_real_position
! 			 either.  So we get the root window x/y for 0/0 in
! 			 the window in the event. */
! 		      count = x_catch_errors (FRAME_X_DISPLAY (f));
!                       XTranslateCoordinates (FRAME_X_DISPLAY (f),
!                                              event.xconfigure.window,
!                                              FRAME_X_DISPLAY_INFO (f)->root_window,
!                                              0, 0,
!                                              &event.xconfigure.x,
!                                              &event.xconfigure.y,
!                                              &child);
! 		      x_uncatch_errors (FRAME_X_DISPLAY (f), count);
  		    }
  #endif /* USE_MOTIF */
  		}

Re: [simon.marshall@misys.com: [21.2.90]: Lesstif menu placement after frame resize]

[Richard Stallman]

    I've checked in this fix in CVS.  Should it go in RC also?

How safe do you think it is?  Might it cause trouble on some system?

Re: [simon.marshall@misys.com: [21.2.90]: Lesstif menu placement after frame resize]

[Harald.Maier.BW]

"Jan D." <jan.h.d@swipnet.se> 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.

See line:

  if (event.xconfigure.x == 0 && event.xconfigure.y == 0)

event.xconfigure.x is always 0 and event.xconfigure.y is 22. I don't
know whether this makes sense because it does not matter whether I
resize in X or Y direction. Really inconsistent or is this the
additional _header border_ ...

If I use a _OR_ condition in the above line

  if (event.xconfigure.x || 0 && event.xconfigure.y == 0)

it seems to work but I don't know which impact this has to other
processing. I tried it for a while and I could not see any harmful
behavior. Anyway the other processing of your patch works _wonderful_
too with windowmaker so I think the fix is really a gift because the
current behavior is extremely annoying. Thanks!

I will test this too on Monday in a CDE conext at work. Currently I
don't have such a context. I dropped last week here a really old CDE
environment.

Harald

> I've checked in this fix in CVS.  Should it go in RC also?
>
> 	Jan D.
>
> Index: xterm.c
> *** xterm.c.~1.753.~	2002-10-03 19:25:46.000000000 +0200
> --- xterm.c	2002-10-03 19:44:17.000000000 +0200
> ***************
> *** 11179,11186 ****
>   		     in the emacs widget, which messes up Motif menus.  */
>   		  if (event.xconfigure.x == 0 && event.xconfigure.y == 0)
>   		    {
> ! 		      event.xconfigure.x = f->output_data.x->widget->core.x;
> ! 		      event.xconfigure.y = f->output_data.x->widget->core.y;
>   		    }
>   #endif /* USE_MOTIF */
>   		}
> --- 11179,11202 ----
>   		     in the emacs widget, which messes up Motif menus.  */
>   		  if (event.xconfigure.x == 0 && event.xconfigure.y == 0)
>   		    {
> !                       Window child;
> ! 		      int count;
> ! 
> ! 		      /* We can get a ConfigureNotify because of a resize,
> ! 			 so we can't just take x and y from the widget.
> ! 			 Since this event may come on something else than
> ! 			 the top level window,  we can't use x_real_position
> ! 			 either.  So we get the root window x/y for 0/0 in
> ! 			 the window in the event. */
> ! 		      count = x_catch_errors (FRAME_X_DISPLAY (f));
> !                       XTranslateCoordinates (FRAME_X_DISPLAY (f),
> !                                              event.xconfigure.window,
> !                                              FRAME_X_DISPLAY_INFO (f)->root_window,
> !                                              0, 0,
> !                                              &event.xconfigure.x,
> !                                              &event.xconfigure.y,
> !                                              &child);
> ! 		      x_uncatch_errors (FRAME_X_DISPLAY (f), count);
>   		    }
>   #endif /* USE_MOTIF */
>   		}

Re: [simon.marshall@misys.com: [21.2.90]: Lesstif menu placement after frame resize]

[Jan D.]

>     I've checked in this fix in CVS.  Should it go in RC also?
> 
> How safe do you think it is?  Might it cause trouble on some system?

Pretty safe.  But there is a much simpler solution that is 100% safe,
and removes the need for any workaround.  Patch below (in CVS).
See also my reply to Harald Maier in this thread.

	Jan D.

Index: src/ChangeLog
*** src/ChangeLog.~1.2893.~	2002-10-06 01:22:42.000000000 +0200
--- src/ChangeLog	2002-10-06 01:30:19.000000000 +0200
***************
*** 1,3 ****
--- 1,10 ----
+ 2002-10-06  Jan D.  <jan.h.d@swipnet.se>
+ 
+ 	* xterm.c (XTread_socket): Fix from 2002-10-03 didn't cover all
+ 	cases.  The correct fix is to pass ReparentNotify to Xt.
+ 	The shell widget interprets ConfigureNotify differently depending
+ 	on if it has been reparented or not.
+ 
  2002-10-05  Markus Rost  <rost@math.ohio-state.edu>
  
  	* editfns.c (Fformat_time_string): Doc fix.
Index: src/xterm.c
*** src/xterm.c.~1.754.~	2002-10-03 19:44:17.000000000 +0200
--- src/xterm.c	2002-10-06 01:31:18.000000000 +0200
***************
*** 10443,10448 ****
--- 10443,10449 ----
  		  x_real_positions (f, &x, &y);
  		  f->output_data.x->left_pos = x;
  		  f->output_data.x->top_pos = y;
+                   goto OTHER;
  		}
  	      break;
  
***************
*** 11173,11204 ****
  		      f->output_data.x->win_gravity = NorthWestGravity;
  		      x_wm_set_size_hint (f, (long) 0, 0);
  		    }
- #ifdef USE_MOTIF
- 		  /* Some window managers pass (0,0) as the location of
- 		     the window, and the Motif event handler stores it
- 		     in the emacs widget, which messes up Motif menus.  */
- 		  if (event.xconfigure.x == 0 && event.xconfigure.y == 0)
- 		    {
-                       Window child;
- 		      int count;
- 
- 		      /* We can get a ConfigureNotify because of a resize,
- 			 so we can't just take x and y from the widget.
- 			 Since this event may come on something else than
- 			 the top level window,  we can't use x_real_position
- 			 either.  So we get the root window x/y for 0/0 in
- 			 the window in the event. */
- 		      count = x_catch_errors (FRAME_X_DISPLAY (f));
-                       XTranslateCoordinates (FRAME_X_DISPLAY (f),
-                                              event.xconfigure.window,
-                                              FRAME_X_DISPLAY_INFO (f)->root_window,
-                                              0, 0,
-                                              &event.xconfigure.x,
-                                              &event.xconfigure.y,
-                                              &child);
- 		      x_uncatch_errors (FRAME_X_DISPLAY (f), count);
- 		    }
- #endif /* USE_MOTIF */
  		}
  	      goto OTHER;
  
--- 11174,11179 ----

Re: [simon.marshall@misys.com: [21.2.90]: Lesstif menu placement after frame resize]

[Jan D.]

> 
> "Jan D." <jan.h.d@swipnet.se> 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.

Re: [simon.marshall@misys.com: [21.2.90]: Lesstif menu placement after frame resize]

[Richard Stallman]

    I have checked in this in CVS and verified it on Windowmaker.

Thank you very much.  It is so good to have the help of a person who
actually understands X.

Re: [simon.marshall@misys.com: [21.2.90]: Lesstif menu placement after frame resize]

[Harald.Maier.BW]

OOps, sorry for resending. I had a bad message header.
---------------------------------------------------------------------------
Richard Stallman <rms@gnu.org> writes:

>     I tried this _one line fix_ too with emacs-21.2.90. Works great !!!
>     Personally, I think we should do the change in RC too because the
>     problem if it happens is really annoying.
>
> Can you test it in RC (if no one else has)?

I checked out the tag EMACS_21_1_RC and configured emacs with the
MOTIF option and recompiled the software with Jan's patch then the
problem with the miss placed menus disappeared. Without the patch the
problem still exists. This is tested with windowmaker 0.65.

Harald

*** xterm.c.~1.650.4.32.~	Tue Oct  1 08:32:38 2002
--- xterm.c	Tue Oct  8 06:29:21 2002
***************
*** 10210,10215 ****
--- 10210,10216 ----
  		  x_real_positions (f, &x, &y);
  		  f->output_data.x->left_pos = x;
  		  f->output_data.x->top_pos = y;
+ 		  goto OTHER;
  		}
  	      break;

,----
| GNU Emacs 21.2.91.2 (i686-pc-linux-gnu, Motif Version 2.1.30) of
| 2002-10-08 on athene
`----