After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 698334 - Mac top-of-screen menu not working properly
Mac top-of-screen menu not working properly
Status: RESOLVED FIXED
Product: gtk-osx
Classification: Other
Component: General
unspecified
Other Mac OS
: Normal normal
: ---
Assigned To: GTK Mac Integration Maintainers
GTK Mac Integration Maintainers
: 669276 700975 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2013-04-18 23:29 UTC by Allin Cottrell
Modified: 2014-01-24 15:53 UTC
See Also:
GNOME target: ---
GNOME version: ---


Description Allin Cottrell 2013-04-18 23:29:25 UTC 
This pertains to version 2.0.1 of gtk-mac-integration in its 64-bit
version (i.e. the gtkosx_application* functions).

gtk-mac-integration lets you populate the Mac's screen-top menu
based on menus defined within GTK. That's good, but the screen-top
menu doesn't work right in two respects. Since these pproblems are
probably closely related I'm filing them as one bug.

1) Latency of response of GTK app: when you select (for example)
/Window/Minimize from the top menu nothing happens... until you
waggle the mouse; then the GTK app gets the signal.

2) When you open an additional window in the GTK app, this window
appears in the listing under the top-level Window menu. So far so
good. But when you close the additional window, its entry in the
Window is not removed, and if you click on that entry the application
segfaults.

These problems are apparent with the sample app, test-integration,
that is supplied with the gtk-mac-integration package.

In case it's relevant: I'm seeing this behavior on OS X 10.6.8,
using gtk-quartz built from the 2.24.17 source package using
Apple's gcc 4.2.1.
Comment 1 John Ralls 2013-04-23 21:28:42 UTC 
I can replicate both issues.
Comment 2 John Ralls 2013-04-29 23:26:29 UTC 
The delay is caused by the need to put the menu's action on the idle queue to get it processed. The main loop then proceeds to one more iteration before processing the idle queue, and then blocks in poll() until it gets an event from quartz:

+ Trace 231877

  • #0 mach_msg_trap
  • #1 mach_msg
  • #2 __CFRunLoopServiceMachPort
  • #3 __CFRunLoopRun
  • #4 CFRunLoopRunSpecific
  • #5 CFRunLoopRunInMode
  • #6 RunCurrentEventLoopInMode
  • #7 ReceiveNextEventCommon
  • #8 BlockUntilNextEventMatchingListInMode
  • #9 _DPSNextEvent
  • #10 -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:]
  • #11 poll_func
  • #12 g_main_context_iterate
  • #13 g_main_loop_run
  • #14 gtk_main
  • #15 main
    at test-integration.c line 761 

The solution is to call g_context_wakeup() in GNSMenuItem activate:, but I need to figure out how to get the context.
Comment 3 John Ralls 2013-05-27 14:51:04 UTC 
*** Bug 700975 has been marked as a duplicate of this bug. ***
Comment 4 John Ralls 2013-06-04 00:45:26 UTC 
And the persistence in the windows menu comes from 1ad25dfb, which was intended to fix bug 647108. In that change Kris moved the [autoreleasepool drain] from gdk_event_check() to gdk_event_dispatch(). As a guess this keeps the NSWindow in memory just long enough that NSApp doesn't see that it's to be destroyed.

One work-around would be to call [NSApp removeWindowsItem: nswindow] in gdk_window_impl_quartz_finalize(). 

Created quartz bug 701571 to track fix.
Comment 5 John Ralls 2013-06-26 00:49:27 UTC 
I've committed a change for the delay problem: It just puts a GDK_NOTHING event to unblock the mainloop so that it will process the idle event with the action callback.
Comment 6 John Ralls 2013-09-29 17:31:17 UTC 
This part of the 701571 problem is also fixed and released in 3.10.0
Comment 7 John Ralls 2013-12-08 15:27:45 UTC 
*** Bug 669276 has been marked as a duplicate of this bug. ***