OK, so the idea is, + validateMenuItem in app delegate gets a first shot at setting the keyboard shortcuts + I override validateMenuItem in my tabbed window and reset the keyboard shortcuts + Other windows stick with the settings arranged by the app delegate
Did I understand correctly? Thanks to all who replied. Cheers, Martin On 19, Oct, 2013, at 02:46 pm, Uli Kusterer <witness.of.teacht...@gmx.net> wrote: > > On 19 Oct 2013, at 14:27, Andy Lee <ag...@mac.com> wrote: >> On Oct 19, 2013, at 6:58 AM, Martin Hewitson <martin.hewit...@aei.mpg.de> >> wrote: >>> Main Window with tabs: >>> close (cmd-shift-w) >>> close tab (cmd-w) >>> >>> All other windows: >>> close (cmd-w) >>> close tab (inactive, no keyboard shortcut) >>> >>> This is pretty much the way things work in Xcode. >>> >>> So, my question is, is there a smart way to do this, or do I need to >>> implement -validateMenuItem: on every window in the app and set the >>> keyboard shortcuts there? >> >> Untested idea: implement windowDidBecomeKey: and windowDidResignKey: in the >> delegate of the window that has tabs and do the switching of shortcuts there. > > Would rather recommend against this. I don’t think there’s any guarantee > given what gets called first, validateMenuItem: or windowDidResignKey:. You > might be obliterating something already set by the incoming window. > >> If you want to be extra careful you could have two ivars that remember what >> the shortcuts were before you changed them to cmd-shift-w and cmd-w. Then >> in windowDidResignKey: plug those shortcuts in rather than hard-code cmd-w >> and @“”. > > Also, while I’m not aware of any localization that doesn’t use Cmd-W for > close, it’s in general a good idea to keep your shortcuts localizable (e.g. > on a German keyboard, there’s no way to type Cmd-~, because it has no ~-key, > so window rotation is done using Cmd-< there). > > I’d recommend adding a validateMenuItem: handler in the application delegate, > as long as you’re aware that this won’t be called for modal panels or windows > that have sheets on them, but since those generally don’t enable the “Close” > menu item, you should be fine. At least then you’re modifying the items. > > Also, I’m not sure whether menu shortcut disambiguation lets you do that, but > have you tried hiding and showing menu items with the same names but > different shortcuts instead of actually changing the items’ shortcut? I.e. > create your menu as > > Close Cmd-Shift-W -> -performCloseForTabbedWindow: > Close Cmd-W -> -performClose: > Close Tab Cmd-W -> -performCloseTab: > Close Tab -> -performCloseTabDummy: > > And then hide/show the “tab” items? That way, localization would be easier, > and you’re not hard-coding any shortcuts. Though that doesn’t solve the issue > of properly restoring the items after you’ve hidden them. > > Cheers, > -- Uli Kusterer > “The Witnesses of TeachText are everywhere...” > http://zathras.de > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Martin Hewitson Albert-Einstein-Institut Max-Planck-Institut fuer Gravitationsphysik und Universitaet Hannover Callinstr. 38, 30167 Hannover, Germany Tel: +49-511-762-17121, Fax: +49-511-762-5861 E-Mail: martin.hewit...@aei.mpg.de WWW: http://www.aei.mpg.de/~hewitson ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
