GNOME Bugzilla – Bug 722476
GtkApplication mac os tracker
Last modified: 2018-05-02 15:55:41 UTC
Lots of work is left to fix remaining issues with GtkApplication and Mac OS. Here's a partial list off the top of my head: - bundle support (ie: discovering bundle path and adjusting Gtk behaviour) - support submenu-action via GtkMenuTracker - dispatch action activations from menus to idles to avoid bug 704374 - add support for hidden-when='macos' items for tweaking menubar layouts - 'traditional menubar' support from bug 722092, if we can get it - make GtkApplication survive after all windows are closed, like a normal Mac OS application - handle accels ⌘Q and ⌘, even without windows open (gdk patch?) - API for setting dock menu via GMenuModel (which should work on gnome-shell too) - support opening files via the NSApplication delegate - punt [NSApp finishLaunching] to an idle so that we only call it after the application has actually done its startup. This would make Mac OS's hacking of the 'Edit' menu (to add the character map) work properly.
- Cocoa (NSApp) handles unknown command line args as files to open and dispatches to openFile from finishLaunching. Since most applications handle opening of files themselves, or GtkApplication handles this by itself, a solution is to set [[NSUserDefaults standardUserDefaults] setObject:@"NO" forKey:@"NSTreatUnknownArgumentsAsOpen"]; This prevents NSApp handling of unknown command line arguments as open files
Created attachment 284497 [details] [review] application-quartz: Implement openFiles delegate This adds a straightforward implementation of the openFiles app delegate method. The call is translated to a call to g_application_open if opening files is supported by the application.
(In reply to comment #0) > - make GtkApplication survive after all windows are closed, like a normal > Mac OS application I've tested a simple solution for gedit, which seems to work fine. I call g_application_hold in the app startup, which ensures the application is kept alive after all the windows are closed. We then make sure to forcefully quite the application in app.quit (if we can) by calling g_application_quit. For now I've implemented it in our GeditAppOSX subclass, but I think this could go in GtkApplication if you agree on the approach. > - handle accels ⌘Q and ⌘, even without windows open (gdk patch?) I've also tested this, and actually the accels are handled correctly already without patching anything. The reason is that the events are directly dispatched by Cocoa to the menu item activation, which in turn dispatches to the app actions.
Ping. Can I get a review on the attached patch?
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gtk/issues/463.