GNOME Bugzilla – Bug 72098
GtkStock should use the accel map
Last modified: 2014-03-13 05:03:55 UTC
So it doesn't get lost, here is a copy of my mailing list post: I was looking at how the GtkStock code handles the keyboard shortcuts associated with stock ids, and think that it could be improved by making use of the GtkAccelMap code (the reason it doesn't currently use this code is that it was written before accel map). Currently the GtkStock code registers a keyboard shortcut with each stock item, and the code in GtkImageMenuItem, etc then creates an accelerator based on the shortcut registered with the stock id. If it was using the accel map, things would probably be a bit simpler. The code in GtkStock should register the keyboard shortcut against an accel path something like "<Stock>/stock-id" (eg. <Stock>/gtk-ok). Then, the code in GtkImageMenuItem could simply set the accel path of the menu item in order to apply the keyboard shortcut, using either gtk_menu_item_set_accel_path() or gtk_widget_set_accel_path(). We would probably want to turn off saving of <Stock>/... accel paths when saving accels though, as they aren't really related to a single app but rather system wide. Some of the benefits of this include: * ensures consistency of stock item shortcuts throughout the application. * would allow customisation of stock item accelerators. Simply load a saved accelerator file with gtk_accel_map_load(). This could be used for localised custom accels, or maybe desktop wide customisation of the accels (I don't know how you would do notification of accel changes though. * make the accel_group argument of gtk_image_menu_item_new_from_stock() superfluous :) (although it can't really be removed at this point ... What do others think about a change like this? I think it would make the architecture a lot simpler, and makes more sense. I don't think it would cause any API bustage. I fully expect this to be ignored for gtk 2.0 though :)
This makes a lot of sense; It needs to wait for 2.2 though so we can try it out and see if there are any unexpected side effects. One small problem is that users will lose any custom accelerators they have set up for stock items in individual apps, since the path will be different after the change.
If we want to do this for 2.2, we need a patch pretty urgently.