Gerd, I'm not too sure how familiar you are with some of the LessTif debugging
features, and it's probably worth repeating on the list anyway.
One of the most usefull is the DEBUGSOURCES environment variable. If you manage
to find a way to cause the problem at will, doing
DEBUGSOURCES=all ./emacs
will spit out tonnes of debug stuff so that we know what LessTif was doing last
when things go bad. If you substitute a colon separated list of source files
for "all" only messages pertaining to that source file will come out. So in the
case of menu problems
DEBUGSOURCES=MenuShell.c:MenuUtils.c ./emacs
should give some usefull info. Of course there is also the debugger to help,
somewhat difficult with lingering Grabs though. There is also a couple of
special ones, I think MENU will still work for tracking menu related stuff...
On 28-Feb-01 at 15:00, Gerd Moellmann ([EMAIL PROTECTED]) wrote:
> Gerd Moellmann <[EMAIL PROTECTED]> writes:
>
> > Now building Emacs with it...
>
> I have it running now, with the default Motif-2.0 API, and I managed
> to lock it up once.
>
> What I did was to pop down the Options menu with a click on Options in
> the menu bar, and then click outside of the menu, in Emacs' text area,
> to close the menu. The popdown was removed, but the pointer shape was
> still the one used in the menu, and the mouse couldn't be used to
> switch to another window. Control-Alt-Backspace still worked to kill
> the X server.
>
> Needless to say, that this bug is now no longer reproducible; I tried
> about 30 times, but nothing happened.
>
> Maybe this is related: When I do what I described above, I see
> that apparently the Emacs frame no longer has the focus (the cursor
> is a hollow box). This is different from the behavior with Motif,
> where the frame regains the focus again after the menu is closed.
>
> In xterm.c, I see that I already tried to work around this problem in
> the past.
> case EnterNotify:
> {
> int from_menu_bar_p = 0;
>
> f = x_any_window_to_frame (dpyinfo, event.xcrossing.window);
>
> #ifdef LESSTIF_VERSION
> /* When clicking outside of a menu bar popup to close
> it, we get a FocusIn/ EnterNotify sequence of
> events. The flag event.xcrossing.focus is not set
> in the EnterNotify event of that sequence because
> the focus is in the menu bar,
> event.xcrossing.window is the frame's X window.
> Unconditionally setting the focus frame to null in
> this case is not the right thing, because no event
> follows that could set the focus frame to the right
> value.
>
> This could be a LessTif bug, but I wasn't able to
> reproduce the behavior in a simple test program.
> On the other hand, Motif seems to not have this
> problem.
>
> (gerd, LessTif 0.92). */
>
> if (!event.xcrossing.focus
> && f
> && f->output_data.x->menubar_widget)
> {
> Window focus;
> int revert;
>
> XGetInputFocus (FRAME_X_DISPLAY (f), &focus, &revert);
> if (focus == XtWindow (f->output_data.x->menubar_widget))
> from_menu_bar_p = 1;
> }
> #endif /* LESSTIF_VERSION */
>
> Alas, I don't remember details anymore; this was added
>
> 1999-06-25 Gerd Moellmann <[EMAIL PROTECTED]>
>
> * xterm.c (XTread_socket): Set mouse_face_frame to zero after
> clearing mouse face.
> (XTread_socket) <EnterNotify> [LESSTIF_VERSION]: If
> event.xcrossing.focus is not set, and focus is in the menu bar,
> set focus frame as if event.xcrossing.focus were set.
>
> And anyway, it doesn't seem to work anymore. Taking out that code
> doesn't change the behavior.
>
>
>
>
