Re: [AD] non blocking menu bug

[Eric Botcazou <ebotcazou@xxxxxxxxxx>]

> Does this mean that if I want to close a dialog from the code, I have to
> wait for the user to close the menu?

For the time being, I guess so. Remember that before the patch, menus were 
fully blocking (the control flow was stuck within a single function). I only 
detangled the situation so as to let the function return even though the 
menu is still active.

> This would be very awkward, because say the user opens a menu, then decides 
> to close the (windowed) application with the close button. The user would 
> expect the application to close, but it will have to remain open until the 
> menu gets discarded by the user...

Obviously awkward.

> I could always try to simulate a keypress to the ESC key, hoping it will
> discard the menu, but this feels rather ugly, no ?

Indeed. I think the right approach would be to implement a menu_message() 
function that, upon being passed a menu, would instruct it to roll back its 
sub-menu hierarchy and properly return on the next call to update_menu(), 
very much like object_message() or dialog_message().

-- 
Eric Botcazou