views:

140

answers:

2

(This is not a question about KVC/KVO and key-value bindings.)

I'm writing an application with a "tools" panel. Every tool can be selected using one-letter key (like "M" - "Move tool"). Tool can be selected even when there is no main window and the tools panel is not selected (not being "key").

Docs say that raw key events are not propagated to the app delegate and document controller (so I cannot rely on onKeyDown since it should happen in a WindowController). But "action events" (keys bound to a selector) are sent to the app, app delegate and document controller.

I know two ways to set such global bindings: through NSMenuItem key equivalents in Interface Builder or using ~/Library/KeyBindings/DefaultKeyBinding.dict file (which specifies global bindings for all apps).

Menu items approach is not good because I don't want to pollute my menu with commands which can be triggered from the tools panel.

I would like to set such bindings programmatically or specify them in a bundled KeyBindings.dict like Xcode and TextMate do.

However, I couldn't find docs or examples how to name such dict file and how to connect it to the app. Xcode uses PBKeyBinding.dict filename, TextMate uses KeyBindings.dict. There's no option for Info.plist to tell app to read the dict file.

Does anybody know how this could be done?

Thanks.

A: 

The documentation says this isn't supported. So, even if you get it working, it could break in a future version of Mac OS X.

I suggest putting all of the tools into a Tools menu. Redundancy is not inherently bad, and a menu could be more easily navigable by people with poor vision, and would serve as a quick reference for those not yet familiar with your tool icons.

If a Tools menu really is pointless, you can set the Hidden property of the Tools menu item (whose submenu is the Tools menu). This way, the Tools menu item is still in the main menu (menu bar), and so should still associate its key bindings with actions, but it is not visible to users.

Peter Hosey
Thanks for reply! Unfortunately, the hidden property disables key equivalents (OS X 10.6.2). But you have a good point on usability of the menu. I think I will keep it as a visible menu for now. I've already spent enough time on this problem.I'll take a look at context menus as well. But they are probably bound to particular window/windowcontroller.
Oleg Andreev
A: 

In fact, this library does what I need:

http://github.com/carpeaqua/SGHotKeysLib

It uses RegisterEventHotKey function (requires linking with Carbon framework).

Oleg Andreev