Motif menu popups not working in CVS

Motif menu popups not working in CVS

[Jan D.]

Hello.

I just noticed that the Motif popup menus aren't working.  That is,
they pop up and down OK, but invoking a menu item has no effect.
The introduction of popup_get_selection_unwind seems to be the cause:

2002-12-21  Richard M. Stallman  <rms@gnu.org>

        * xmenu.c (popup_get_selection): Now static.  New arg DO_TIMERS.
        If it is non-nil, run timers.  Use an unwind-protect to requeue
        the events that were read ahead.
        (popup_get_selection_unwind): New subroutine.
        (popup_get_selection_queue): File-scope variable now holds that queue.
        (xmenu_show): Pass 0 for DO_TIMERS to popup_get_selection.
        (xdialog_show): Pass 1 for DO_TIMERS to popup_get_selection.
        Use an unwind-protect to pop down the dialog box.
        (xdialog_show_unwind): New subroutine implements that.


It is some sort of race condition here, it seems that
popup_get_selection exits and removes the popup before Motif has
had a chance to invoke its callback for the menu item.  Lucid
menus work OK.

I have a patch for this, but I have a question.  In popup_get_selection
events that are not acted upon immediately are saved in a queue.  Later
when the menu pops down, these events are reinserted into the X event
queue to be re-read by Emacs "normal" event handling.

I don't think this is needed.  Removing this and running shows no
ill effects, in fact, no difference between saving and not saving
can be seen for dialogs or popup menus.

The only events that do get saved are EnterNotify, LeaveNotify,
FocusOut, FocusIn and MotionNotify.  Loosing these is no big deal, since
the menu has the pointer and keyboard grabbed anyway.  What kind of
problem is saving these events supposed to solve?  If we can remove
the saving of events, the popup_get_selection_unwind can be removed also.

Thanks,
	Jan D.

Re: Motif menu popups not working in CVS

[Richard Stallman]

    It is some sort of race condition here, it seems that
    popup_get_selection exits and removes the popup before Motif has
    had a chance to invoke its callback for the menu item.  Lucid
    menus work OK.

That is strange.  Where is popup_activated_flag getting cleared
in the case that fails?

    The only events that do get saved are EnterNotify, LeaveNotify,
    FocusOut, FocusIn and MotionNotify.  Losing these is no big deal, since
    the menu has the pointer and keyboard grabbed anyway.

Could you explain that reasoning?  I don't see how the conclusion
follows.  I'm sure the code was added to solve a problem.

Re: Motif menu popups not working in CVS

[Jan D.]

söndagen den 5 januari 2003 kl 19.33 skrev Richard Stallman:

>     It is some sort of race condition here, it seems that
>     popup_get_selection exits and removes the popup before Motif has
>     had a chance to invoke its callback for the menu item.  Lucid
>     menus work OK.
>
> That is strange.  Where is popup_activated_flag getting cleared
> in the case that fails?

In the if-branch for ButtonRelease.  It may be that Motif does not
calls the activate callback directly on the ButtonRelease event.

>     The only events that do get saved are EnterNotify, LeaveNotify,
>     FocusOut, FocusIn and MotionNotify.  Losing these is no big deal, since
>     the menu has the pointer and keyboard grabbed anyway.
>
> Could you explain that reasoning?  I don't see how the conclusion
> follows.  I'm sure the code was added to solve a problem.

I'm sure it was, but I am not sure the problem remains.  Since the
popup/dialog has a grab, a FocusOut and Leave is generated when the
popup/dialog is posted.  A new FocusIn and Enter notify will be
generated when the popup/dialog is removed (if Emacs gets the focus),
so keeping track of what happend in between is not useful, it is just
the final state that is interesting.  In fact, a common optimization is
to compress Enter-Leave sequences that occur quickly after each other
(GTK does this).

The MotionNotify events will have the popup/dialog window in the event,
since a grab has been done, so there will be no action for these events
anyway when they are replayed.

	Jan D.

Re: Motif menu popups not working in CVS

[Jan D.]

> 
> >     The only events that do get saved are EnterNotify, LeaveNotify,
> >     FocusOut, FocusIn and MotionNotify.  Losing these is no big deal, since
> >     the menu has the pointer and keyboard grabbed anyway.
> >
> > Could you explain that reasoning?  I don't see how the conclusion
> > follows.  I'm sure the code was added to solve a problem.
> 
> I'm sure it was, but I am not sure the problem remains.  Since the
> popup/dialog has a grab, a FocusOut and Leave is generated when the
> popup/dialog is posted.  A new FocusIn and Enter notify will be
> generated when the popup/dialog is removed (if Emacs gets the focus),
> so keeping track of what happend in between is not useful, it is just
> the final state that is interesting.  In fact, a common optimization is
> to compress Enter-Leave sequences that occur quickly after each other
> (GTK does this).
> 
> The MotionNotify events will have the popup/dialog window in the event,
> since a grab has been done, so there will be no action for these events
> anyway when they are replayed.

We can do this even better.  The GTK port splits XTread_socket in to
two functions, one that loops and one that handles one event.

We can make a new function, x_dispatch_event, that calls the function that
handles one event, and use x_dispatch_event instead of XtDispatchEvent.

Then we definitly can remove the saving and reinsertions of event.
process_expose_from_menu function can be removed also.  If we use this 
for the Motif file selection dialog, we get the added bonus that
expose of the frame under the dialog is handeled much better.
Now, it relies on a signal getting trough in a short space of time,
and if that time frame is missed, a redraw does not get done.

	Jan D.