bug#44333: 27.1; macOS menu bar 2-clicks

["Mattias Engdegård" <mattiase@acm.org>]

[-- Attachment #1: Type: text/plain, Size: 1085 bytes --]

31 okt. 2020 kl. 16.01 skrev Alan Third <alan@idiocy.org>:

> IIRC the problem is due to the reposting of the menu click event so
> the menu can be populated when lisp is running. The Mac port doesn't
> have this problem most probably because it's a completely different
> architecture but it has the GUI and lisp parts split into two separate
> threads which is one way I can see of fixing this.

Last time I looked it seemed that the Mac port actually did synthesise events but used some other means (Carbon?), but I may be wrong.


> If anyone else has a simpler solution I'd love to hear it.

Maybe we are overthinking it. I don't think the Cocoa event loop really is running in a different thread. Anecdotal evidence (printf!) indicates that it isn't.

(https://debbugs.gnu.org/cgi/bugreport.cgi?bug=32864#38 has a previous investigation into the matter.)

I just did the simplest thing possible and it works (with a slight latency at times, but perhaps tolerable). I'd like to know what's wrong with running Lisp in the event loop. It does appear safe to me.


[-- Attachment #2: macos-1-click-menu-bar.diff --]
[-- Type: application/octet-stream, Size: 1595 bytes --]

diff --git a/src/nsmenu.m b/src/nsmenu.m
index a286a80da1..4a99df31fb 100644
--- a/src/nsmenu.m
+++ b/src/nsmenu.m
@@ -466,7 +466,7 @@
 void
 ns_activate_menubar (struct frame *f)
 {
-#ifdef NS_IMPL_COCOA
+#if 0 && defined NS_IMPL_COCOA
   ns_update_menubar (f, true, nil);
   ns_check_pending_open_menu ();
 #endif
@@ -514,7 +514,7 @@ - (void)setFrame: (struct frame *)f
   frame = f;
 }
 
-#ifdef NS_IMPL_COCOA
+#if 0 && defined NS_IMPL_COCOA
 -(void)trackingNotification:(NSNotification *)notification
 {
   /* Update menu in menuNeedsUpdate only while tracking menus.  */
@@ -573,10 +573,12 @@ - (void)menuNeedsUpdate: (NSMenu *)menu
      From 10.6 on, we could also use -[NSMenu propertiesToUpdate]: In the
      key press case, NSMenuPropertyItemImage (e.g.) won't be set.
   */
+#if 0
   if (trackingMenu == 0)
     return;
+#endif
 /*fprintf (stderr, "Updating menu '%s'\n", [[self title] UTF8String]); NSLog (@"%@\n", event); */
-#ifdef NS_IMPL_GNUSTEP
+#if 1 || defined NS_IMPL_GNUSTEP
   /* Don't know how to do this for anything other than Mac OS X 10.5 and later.
      This is wrong, as it might run Lisp code in the event loop.  */
   ns_update_menubar (frame, true, self);
diff --git a/src/nsterm.m b/src/nsterm.m
index fa38350a2f..8f5658640f 100644
--- a/src/nsterm.m
+++ b/src/nsterm.m
@@ -4607,7 +4607,7 @@ in certain situations (rapid incoming events).
 #endif
 
 /* GNUstep does not have cancelTracking.  */
-#ifdef NS_IMPL_COCOA
+#if 0 && defined NS_IMPL_COCOA
 /* Check if menu open should be canceled or continued as normal.  */
 void
 ns_check_menu_open (NSMenu *menu)