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

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

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

David Reitter-6
When a modified buffer is killed through some mouse action, I get a  
``yes-or-no-p'' question in form of a single submenu drawn on the  
screen, in the middle of the frame.

When I then click somewhere else in the frame (outside the menu), the  
adopted semantics are "no" rather than "quit". yes-or-no-p returns  
nil just as if "no" had been selected.

Verify this with the following code:

(print (progn
      (setq last-nonmenu-event nil)
      (yes-or-no-p "Save this buffer to file before closing window? ")
      )
        )

The expected behavior would be that a "quit" is carried out.  
Otherwise, users can lose changes to a file just because they did not  
hit the right "yes", or more likely, because they think they can  
cancel the operation by just clicking somewhere else. Cancelling the  
operation is exactly what standard GUIs do in such a situation, and  
it's a good behavior.




In GNU Emacs 22.0.50.1 (powerpc-apple-darwin8.1.0)
  of 2005-06-01 on madonna - Aquamacs Distribution 0.9.2 beta-5
Distributor `Apple Computers' version (10 4 1) .
configured using `configure '--without-x' '--prefix=/usr/local''







Reply | Threaded
Open this post in threaded view
|

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






Reply | Threaded
Open this post in threaded view
|

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

Jan D.-2
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.







Reply | Threaded
Open this post in threaded view
|

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.






Reply | Threaded
Open this post in threaded view
|

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

Jan D.-2
In reply to this post by David Reitter-6
> 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.







Reply | Threaded
Open this post in threaded view
|

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

YAMAMOTO Mitsuharu
In reply to this post by Jan D.-2
>>>>> On Sat, 4 Jun 2005 09:04:02 +0200, jhd <[hidden email]> 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
                                [hidden email]

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);
}






Reply | Threaded
Open this post in threaded view
|

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

Richard Stallman
In reply to this post by Jan D.-2
    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.






Reply | Threaded
Open this post in threaded view
|

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

Jan D.-2
In reply to this post by YAMAMOTO Mitsuharu
>
> 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.