The only example of this that I am aware of is ⌘Y when there is no version control system used for the current project: Here we get a menu with init/checkout/help items from some of the SCM bundles and it looked bad when TextMate would use separators for these items.
Apparently clang (now?) support transferring non-POD types from and to Objective-C++ methods, eliminating the need for doing this by passing a (const) reference.
This means we don’t need to know if there is a selection when creating the menu items and long-term it’ll be easier to introduce more complex updating, e.g. make the title a format string to allow referencing TM_DISPLAYNAME or disable the menu item if its requirements cannot be met.
The rendering doesn’t mimic the system 100%, for example the key equivalents are not centered on the split between modifiers and the key, nor are F-keys rendered using a smaller font / menu glyph.
On the plus side though, now all keys are rendered. Previously keys shared with other (non bundle) menu items would only be shown for one of the items sharing the key, and some keys would simply not be shown (e.g. ⌃#).
Also, bundle menu items no longer “eclipse” regular menu items, which could previously happen even when the bundle menu item wouldn’t fire (as it was scoped for something else than the current context).
Fixes#894.
We now explicitly disable it for targets that hasn’t yet been upgraded to ARC. This way, it’s easier to get an overview of which targets hasn’t yet been upgraded and ensures new targets has ARC enabled.
We now have:
- performBundleItem:
- performBundleItemWithUUIDString:
- performBundleItemWithUUIDStringFrom:
I’m leaning toward changing the prefix, as ‘perform’ is mainly action methods invoked as a direct response to some user action (with that action part of the name), but haven’t found a better prefix yet.
This way we can have “Lookup Word” in the Source menu being a proxy for “lookup.documentation” and simply rendered as disabled when the current language have no such functionality.
This is to allow a bundle item to display another key than the one assigned to the item, e.g. when the bundle item is matched by a proxy item it should show that item’s key equivalent.
Since we overload performKeyEquivalent: for the main menu to not search the bundle menus, there should no longer be a need to try and prevent the system from interpreting key equivalents for bundle menu items.
The old techniques used to set key equivalents no longer work. Unfortunately, this technique is only a workaround and is not pixel-for-pixel identical due to the way NSMenuItem lays itself out when rendering a key equivalent; but I think it's the best that can be done for now.
