GNOME Bugzilla – Bug 708513
Several new functions, and modifications for cosmetic improvements to apps
Last modified: 2014-01-24 15:53:07 UTC
These patches add the following new functions to gtkosxapplication_quartz: gtkosx_application_insert_app_menu_item_from_widget gtkosx_application_set_menu_bar_from_widget gtkosx_application_set_help_menu_from_widget gtkosx_application_set_preferences_item_from_widget gtkosx_application_set_about_item_from_widget They are convenience functions that simplify the workflow of GtkWidget *item = gtk_ui_manager_get_widget (ui_manager, item_name); gtkosx_application_insert_app_menu_item (self, item, index); gtkosx_application_insert_app_menu_item (self, GtkMenuSeparator, index +1); gtk_widget_hide (item); to a single function call. Mainly they just call gtk_ui_manager_get_widget (ui_manager, item_name) forward arguments to gtkosx_application_insert_app_menu_item, along with whatever additional cosmetics are expected by OS X convention, such as capitalization, changing the key equivalent, or appending a menu separator (subject to an additional argument for TRUE|FALSE). The next batch of new functions is: gtkosx_application_reposition_help, explicitly moves Help to the end of the OS X menu bar, since this doesn't always work the way the existing documentation describes. A last ditch function to fix the situation. gtkosx_application_scrub_menu_separators, goes through the top level menus within the OS X menu bar and hides separator items if they are the first item in the menu, the last item, or preceded by another separator. gtkosx_application_set_dock_icon_from_theme, loads a forced 512 px vector icon from the specified icon theme. 512 is the largest size currently available in the OS X icon spec, and forcing it as vector makes it look better in the dock. Finally, a couple changes to create_apple_menu: adds variable NSString *appName = [[[NSRunningApplication currentApplication] localizedName] capitalizedString]. This name is appended to relevant app menu items to follow the OS X convention of Item Appname. Also, puts the NSLocalizedStringFromTable into gtkosx_application_set_help_menu. I am not very familiar with Gtk conventions, so if something is not correct, please let me know, and I will try to fix it. I hope you will consider committing these patches.
Created attachment 255458 [details] [review] Adds new function prototypes described above
Created attachment 255459 [details] [review] Adds new functions and modifications as described above
Created attachment 255494 [details] [review] Example of how these new functions are used in a Gnumeric patch Just thought I'd include the patch I'm using for gtk-osx-application in Gnumeric, to show how the new proposed functions can be used.
I will not add API to gtk-mac-integration. While it works with Gtk3, Gtk3 also offers more direct integration with the Mac menus which doesn't require gtk-mac-integration. That's the direction that project developers should be taking: Upgrading to Gtk3 with GMenuModel & GMenu from GIO. Your "scrub" fix takes entirely the wrong approach: That needs to happen in cocoa_menu_item_add_submenu() or it will lose the effect every time the menu gets reloaded. Please see https://wiki.gnome.org/GnomeLove/SubmittingPatches for instructions about creating patches to Gnome projects. Finally, an observation: You are doing a grave disservice to the Gnumeric developers by substantially altering their code. When users have problems with the results of your patches, they'll be filing bugs against Gnumeric, not with you or MacPorts.
(In reply to comment #4) > I will not add API to gtk-mac-integration. While it works with Gtk3, Gtk3 also > offers more direct integration with the Mac menus which doesn't require > gtk-mac-integration. That's the direction that project developers should be > taking: Upgrading to Gtk3 with GMenuModel & GMenu from GIO. I saw such usage in the gtk3 demo apps, but I was unable to get examples to work within Gnumeric; and I'm not sure that they are going to prioritize rewriting their app for a tiny minority of users, at least not any time soon. But if I understand you correctly, gtk-osx-application is considered obsolete/legacy software? Is there documentation or API for accomplishing the same type of menu item rearrangements and dock icons in Gtk3? That would be infinitely preferable. > Your "scrub" fix takes entirely the wrong approach: That needs to happen in > cocoa_menu_item_add_submenu() or it will lose the effect every time the menu > gets reloaded. That's easily changed. If I understand correctly then, submenus are refreshed as a whole, not as individual menu items within the submenu. That could explain another issue where a submenu refused to remain hidden... > Please see https://wiki.gnome.org/GnomeLove/SubmittingPatches for instructions > about creating patches to Gnome projects. > > Finally, an observation: You are doing a grave disservice to the Gnumeric > developers by substantially altering their code. When users have problems with > the results of your patches, they'll be filing bugs against Gnumeric, not with > you or MacPorts. I don't think Gnumeric has any intention of ever accepting gtk-osx based patches, they had previously had mac-integration patches, ifdefs and makefile patches available to them for years, yet never incorporated them. This patch is only applied within the MacPorts environment when a user specifically requests the +quartz variant for Gnumeric, Goffice, and Gtk3.
(In reply to comment #4) and 5 Also, if Gtk3 has native methods to accomplish what was provided by gtk-osx-application, then the Gtk documentation on http://www.gtk.org/download/macos.php and https://wiki.gnome.org/GTK+/OSX/Integration should be updated to show that instead. Furthemore if gtk-osx-application is obsoleted by native Gtk3 methods, then I personally see no reason to bother with these patches here at all. If you would like to dissect and fold them into the appropriate Gtk3 methods, then feel free, or direct me to the relevant code and I will investigate it. Finally, even if after all that, a couple short #ifdef wrapped statements are still required within the Gnumeric code, I think they would be far more open to it if it is part of Gtk3 instead of an extension. it would also make my life easier not having to deal with conditionally patching the Gnumeric MacPorts port files.
(In reply to comment #6) > (In reply to comment #4) and 5 > Also, if Gtk3 has native methods to accomplish what was provided by > gtk-osx-application, then the Gtk documentation on > http://www.gtk.org/download/macos.php and > https://wiki.gnome.org/GTK+/OSX/Integration should be updated to show that > instead. > > Furthemore if gtk-osx-application is obsoleted by native Gtk3 methods, then I > personally see no reason to bother with these patches here at all. If you > would like to dissect and fold them into the appropriate Gtk3 methods, then > feel free, or direct me to the relevant code and I will investigate it. > > Finally, even if after all that, a couple short #ifdef wrapped statements are > still required within the Gnumeric code, I think they would be far more open to > it if it is part of Gtk3 instead of an extension. it would also make my life > easier not having to deal with conditionally patching the Gnumeric MacPorts > port files. It's better than that. Once the application is rewritten to use GApplication, GMenu, GMenuModel, and friends, no special code is required in the application at all. It's all handled by the abstraction code in GApplication.
(In reply to comment #7) > It's better than that. Once the application is rewritten to use GApplication, > GMenu, GMenuModel, and friends, no special code is required in the application > at all. It's all handled by the abstraction code in GApplication. In that case, I would much rather help them do that than muck about with this. So unless you have any objections, I would like to close this ticket as obsolete, along with the Gnumeric key equivalent bug.