If we're going to eventually have configurable menus we should think a bit about how registerMenuItem(), hotkeys, and configurability will all interact.
Setting hotkeys aside for the moment the problem boils down to this: When someone is laying out a menu what is the token that represents a particular item? For menu items built into fontforge this can be whatever we want it to be as long as something about the represents the window type (charview, fontview, etc). So maybe a shortish unique string. This would not be the string that appears in the menu because that should be configurable and localizeable. But perhaps there should be a default menu string and (therefore) a default set of localizations.
In that case, what would represent a registerMenuItem item? We could make the author specify a string but we don't now and anyway that raises the problem of clashes, and therefore token "registration". So maybe the way to go is some concatenation of the sub-menu and menu names the item was registered with, preceded by or associated with a window identifier (CV or FV). Clashes are still possible then but unlikely enough that it's viable to punt that problem to the end-user.
For Hotkeys I'm inclined to allow a default to be specified for each item as it is defined. If the default is already in use, or if the user has specified a different hotkey for the item, it is ignored. That way if you're laying out your own menu you only need to specify the hotkeys for to override that default.
If and when it comes to it there should probably be a "fake" item that represents all or part of the Tools menu, so that a user has the option of inserting those items as a group rather than tracking them individually.
If we're going to eventually have configurable menus we should think a bit about how
registerMenuItem(), hotkeys, and configurability will all interact.Setting hotkeys aside for the moment the problem boils down to this: When someone is laying out a menu what is the token that represents a particular item? For menu items built into fontforge this can be whatever we want it to be as long as something about the represents the window type (charview, fontview, etc). So maybe a shortish unique string. This would not be the string that appears in the menu because that should be configurable and localizeable. But perhaps there should be a default menu string and (therefore) a default set of localizations.
In that case, what would represent a registerMenuItem item? We could make the author specify a string but we don't now and anyway that raises the problem of clashes, and therefore token "registration". So maybe the way to go is some concatenation of the sub-menu and menu names the item was registered with, preceded by or associated with a window identifier (CV or FV). Clashes are still possible then but unlikely enough that it's viable to punt that problem to the end-user.
For Hotkeys I'm inclined to allow a default to be specified for each item as it is defined. If the default is already in use, or if the user has specified a different hotkey for the item, it is ignored. That way if you're laying out your own menu you only need to specify the hotkeys for to override that default.
If and when it comes to it there should probably be a "fake" item that represents all or part of the Tools menu, so that a user has the option of inserting those items as a group rather than tracking them individually.