bug#5876: [Aquamacs-bugs] Re: yes-or-no-p menu

bug#5876: [Aquamacs-bugs] Re: yes-or-no-p menu

[Richard Stallman]

Does this patch fix it?

*** xmenu.c	24 May 2005 19:13:15 -0400	1.290
--- xmenu.c	03 Jun 2005 18:32:12 -0400	
***************
*** 1235,1240 ****
--- 1235,1243 ----
        if (event.type == ButtonRelease
            && dpyinfo->display == event.xbutton.display)
          {
+ 	  if (x_any_window_to_frame (dpyinfo, event.xexpose.window))
+ 	    popup_activated_flag = 0;
+ 	    
            dpyinfo->grabbed &= ~(1 << event.xbutton.button);
  #ifdef USE_MOTIF /* Pretending that the event came from a
                      Btn1Down seems the only way to convince Motif to

bug#5894: [Aquamacs-bugs] Re: yes-or-no-p menu

[jhd]

4 jun 2005 kl. 00.33 skrev Richard Stallman:

> Does this patch fix it?
>
> *** xmenu.c    24 May 2005 19:13:15 -0400    1.290
> --- xmenu.c    03 Jun 2005 18:32:12 -0400
> ***************
> *** 1235,1240 ****
> --- 1235,1243 ----
>         if (event.type == ButtonRelease
>             && dpyinfo->display == event.xbutton.display)
>           {
> +       if (x_any_window_to_frame (dpyinfo, event.xexpose.window))
> +         popup_activated_flag = 0;
> +
>             dpyinfo->grabbed &= ~(1 << event.xbutton.button);
>   #ifdef USE_MOTIF /* Pretending that the event came from a
>                       Btn1Down seems the only way to convince Motif to

xmenu.c is not used on Mac AFAIK, Mac uses macmenu.c instead.  The  
behaviour reported seems to be particular to the Mac port, on X11 yes- 
or-no-p does a quit in the case described.  I briefly looked at it a  
while back, and I can fix the quit behaviour to be the same as on X11.

But I would also like C-g to do a quit as it does on X11, but I could  
not find a way to make PopUpMenuSelect return and pop down the menu  
form within an event handler function.  Anybody knows how to do that?

     Jan D.

bug#5906: [Aquamacs-bugs] Re: yes-or-no-p menu

[Richard Stallman]

    xmenu.c is not used on Mac AFAIK, Mac uses macmenu.c instead.  The  
    behaviour reported seems to be particular to the Mac port, on X11 yes- 
    or-no-p does a quit in the case described.

It did fail for me, on GNU/Linux, before I made that patch, and that
patch fixed it for me.  However, I suppose a patch is also needed in
macmenu.c.  And maybe in w32menu.c.

bug#5882: [Aquamacs-bugs] Re: yes-or-no-p menu

[jhd]

> Does this patch fix it?
>
> *** xmenu.c     24 May 2005 19:13:15 -0400      1.290
> --- xmenu.c     03 Jun 2005 18:32:12 -0400
> ***************
> *** 1235,1240 ****
> --- 1235,1243 ----
>         if (event.type == ButtonRelease
>             && dpyinfo->display == event.xbutton.display)
>           {
> +         if (x_any_window_to_frame (dpyinfo, event.xexpose.window))
> +           popup_activated_flag = 0;
> +
>             dpyinfo->grabbed &= ~(1 << event.xbutton.button);
>   #ifdef USE_MOTIF /* Pretending that the event came from a
>                       Btn1Down seems the only way to convince Motif to



What this patch does is that it makes the dialog pop down for a click  
in an Emacs window for Lesstif/Motif and Lucid only.  We discussed  
this before, this is not the way a dialog shall behave (as seen in  
other GUI programs), and the code was explicitly changed to not pop  
down dialogs on click outside the dialog around december 2004.

However, it *is* the way a menu shall behave.  Menus are used instead  
of dialogs when compiling on X11 without a toolkit, and on Mac (and  
perhaps W32, I am not sure).  So on those ports, the dialog (really  
menu) shall pop down on a click outside the menu.  And for X11 it  
already does that, and now it does that for Mac also.  I suggest  
reverting this patch.

     Jan D.

bug#5871: [Aquamacs-bugs] Re: yes-or-no-p menu

[YAMAMOTO Mitsuharu]

>>>>> On Sat, 4 Jun 2005 09:04:02 +0200, jhd <jan.h.d@swipnet.se> said:

> But I would also like C-g to do a quit as it does on X11, but I
> could not find a way to make PopUpMenuSelect return and pop down the
> menu form within an event handler function.  Anybody knows how to do
> that?

Installing a Carbon Event handler on a menu seems to work, but only
for Mac OS X 10.3 and later because CancelMenuTracking is not
available on earlier versions.

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

static pascal OSStatus
mac_handle_menu_event (next_handler, event, data)
     EventHandlerCallRef next_handler;
     EventRef event;
     void *data;
{
  MenuRef menu = data;

  switch (GetEventKind (event))
    {
    case kEventRawKeyDown:
      {
	char c;

	GetEventParameter (event, kEventParamKeyMacCharCodes, typeChar,
			   NULL, sizeof (char), NULL, &c);
	if (c == 7)		/* C-g */
	  {
	    CancelMenuTracking (menu, true, 0);

	    return noErr;
	  }
	else
	  return CallNextEventHandler (next_handler, event);
      }
      break;

    default:
      break;
    }

  return eventNotHandledErr;
}

static OSErr
install_menu_handler (menu)
     MenuRef menu;
{
  EventTypeSpec specs[] = {{kEventClassKeyboard, kEventRawKeyDown}};

  return InstallMenuEventHandler (menu, mac_handle_menu_event,
				  GetEventTypeCount (specs), specs,
				  menu, NULL);
}

bug#5877: [Aquamacs-bugs] Re: yes-or-no-p menu

[Richard Stallman]

    What this patch does is that it makes the dialog pop down for a click  
    in an Emacs window for Lesstif/Motif and Lucid only.  We discussed  
    this before, this is not the way a dialog shall behave (as seen in  
    other GUI programs), and the code was explicitly changed to not pop  
    down dialogs on click outside the dialog around december 2004.

I see now that you are right.
Sorry.

bug#5893: [Aquamacs-bugs] Re: yes-or-no-p menu

[jhd]

>
> Installing a Carbon Event handler on a menu seems to work, but only
> for Mac OS X 10.3 and later because CancelMenuTracking is not
> available on earlier versions.

Thanks.  I guess the best I can do is to put in a configure test for  
CancelMenuTracking and use it if available.

     Jan D.