Re: Setting key equivalent for menus depending on window
Re: Setting key equivalent for menus depending on window
- Subject: Re: Setting key equivalent for menus depending on window
- From: Martin Hewitson <email@hidden>
- Date: Sat, 19 Oct 2013 19:28:56 +0200
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 <email@hidden> wrote:
>
> On 19 Oct 2013, at 14:27, Andy Lee <email@hidden> wrote:
>> On Oct 19, 2013, at 6:58 AM, Martin Hewitson <email@hidden> 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: email@hidden
WWW: http://www.aei.mpg.de/~hewitson
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden