Re: NSMenuItem’s userKeyEquivalent lost if changing title

2016-09-20 Thread Kyle Sluder
On Tue, Sep 20, 2016, at 02:56 AM, Allan Odgaard wrote: > Minor improvement on the code below, when title is equal to plainTitle > we can set attributedTitle to nil. > > This restores proper rendering of disabled items. > > Finder should be able to do the same, as when its dynamic menu items

Re: NSMenuItem’s userKeyEquivalent lost if changing title

2016-09-20 Thread Allan Odgaard
Minor improvement on the code below, when title is equal to plainTitle we can set attributedTitle to nil. This restores proper rendering of disabled items. Finder should be able to do the same, as when its dynamic menu items are disabled, they would normally not contain the dynamic part (info

Re: NSMenuItem’s userKeyEquivalent lost if changing title

2016-09-20 Thread Allan Odgaard
On 20 Sep 2016, at 9:11, Dave Lyons wrote: (Ooh! I know that one!) The custom shortcut for Finder's File > Compress menu item continues to work, because Finder goes slightly out if its way to achieve it. The item's -title remains unchanged as ”Compress”, even when you see "Compress “foo”"

Re: NSMenuItem’s userKeyEquivalent lost if changing title

2016-09-20 Thread Dave Lyons
(Ooh! I know that one!) The custom shortcut for Finder's File > Compress menu item continues to work, because Finder goes slightly out if its way to achieve it. The item's -title remains unchanged as ”Compress”, even when you see "Compress “foo”" or "Compress 42 Items” -- in that case, you're

NSMenuItem’s userKeyEquivalent lost if changing title

2016-09-20 Thread Allan Odgaard
Some menu items use titles dynamically updated in validateMenuItem: (based on application state, like if there are selected content). This seems to be incompatible with System Preferences → Keyboard → Shortcuts → App Shortcuts, as the menu item check for custom bindings using their current