17

Let's say you're creating a game for Mac OS X. In fact, let's say you're creating Quake, only it's 2011 and you'd prefer to only use modern, non-deprecated frameworks.

You want your game to be notified when the user presses (or releases) a key, any key, on the keyboard. This includes modifer keys, like shift and control. Edited to add: Also, you want to know if the left or right version of a modifier key was pressed.

You also want your game to have a config screen, where the user can inspect and modify the keyboard config. It should contain things like:

  • Move forward: W
  • Jump: SPACE
  • Fire: LCTRL

What do you do? I've been trying to find a good answer to this for a day or so now, but haven't succeeded.

This is what I've came up with:

  • Subclass NSResponder, implement keyUp: and keyDown:, like in this answer. A problem with this approach, is that keyUp: and keyDown: won't get called when the user presses only a modifier key. To work around that, you can implement flagsChanged:, but that feels like a hack.
  • Use a Quartz Event Tap. This only works if the app runs as root, or the user has enabled access for assistive devices. Also, modifier key events still do not count as regular key events.
  • Use the HIToolbox. There is virtually no mention at all of it in the 10.6 developer docs. It appears to be very, very deprecated.

So, what's the proper way to do this? This really feels like a problem that should have a well-known, well-documented solution. It's not like games are incredibly niche.

Community
  • 1
  • 1
sarnesjo
  • 6,054
  • 2
  • 20
  • 17
  • FWIW, I don’t think `-flagsChanged:` or `NSFlagsChangedMask` is a hack. It is the documented way of being notified of changes in modifier keys like Control. –  May 01 '11 at 00:44
  • I didn't mean to say that flagsChanged: is a hack, but rather that using it *for this purpose* feels like a hack. If you're writing, say, a text editor, treating modifier key events differently is a great idea! However, if you want to know which key was just pressed, no matter what kind of key that may be, flagsChanged: does not seem like a good fit to me. Sure, you could store the value of [event modifierFlags] and diff against that -- it could be done -- but it's enough of a kludge that I feel there should a better, more straightforward way. Is there? – sarnesjo May 01 '11 at 01:05
  • I don’t think there is another way. As far as I can tell, Cocoa follows the reasoning you’ve described: in most cases, modifier keys aren’t relevant by themselves alone. That said, you could abstract `-keyDown:`, `-keyUp:`, `-flagsChanged:` into one or two methods that effectively do the actions in your application — those three methods would simply filter events and call your custom method(s). –  May 01 '11 at 01:11
  • Gah, weird behaviour. I’ve solved it by having a static counter: in your `if` part, I increment the counter and consider it a key down if the counter is less than 2; otherwise, I decrement the counter and consider it a key up. In the `else` part, I decrement the counter and consider it a key up. I’ve only done this for a single key; you’d have to have a counter for each modifier key. –  May 01 '11 at 02:15
  • I’m not sure that’s a good solution because that 2 is constant and I guess it’s theoretically possible that the user has more than one keyboard and that 2 should be 4. I can’t test this, though. –  May 01 '11 at 02:25
  • There are a few problems with that approach, though. First off, a MacBook with an external keyboard has four cmd keys, not two (same with shift and alt). Sure, this is an edge case, but this is still a problem that should not exist! A less contrived problem occurs if an event gets "lost". Example: user presses shift, switches to another app, then releases shift. The counter now has the wrong value. See what I mean about flagsChanged: not being a good fit here? – sarnesjo May 01 '11 at 02:25
  • Yeah, agreed. I’ll chime in if I can think of a better solution. You might want to consider asking this on cocoa-dev at lists.apple.com. –  May 01 '11 at 02:28
  • Yeah, posting it there or on cocoa-unbound is worth a shot. I'll do that tomorrow. Thanks for your input! – sarnesjo May 01 '11 at 02:32
  • Maybe [OpenEmu](https://github.com/OpenEmu/OpenEmu/) handles this scenario; it might be worth looking at its source. –  May 01 '11 at 02:37
  • does -flagsChanged only fire when subclassing NSResponder? – 2075 Apr 20 '16 at 17:01

2 Answers2

7

As others have said, there’s nothing wrong with using -flagsChanged:. There is another option: use the IOKit HID API. You should be using this anyway for joystick/gamepad input, and arguably mouse input; it may or may not be convenient for keyboard input too, depending on what you’re doing.

Jens Ayton
  • 14,532
  • 3
  • 33
  • 47
  • Well, like I mentioned in the comments on my question, there *is* something wrong with using flagsChanged: for this, namely that it doesn't seem to separate the left and right modifier key. (That requirement wasn't in my original question, though. My bad.) The IOKit HID API looks promising. I will look into it! – sarnesjo May 01 '11 at 10:21
  • Yup, that's a winner. I'm having a bit of a hard time wrapping my head around the API, but based on what I've been able to hack up so far, this provides what I need. Cheers! – sarnesjo May 01 '11 at 23:39
  • 2
    One complication with using HID for key events is mapping keys to characters and symbols for configuration interfaces. Conveniently, I’ve written a library for this. I haven’t tested it for years, but last I heard it worked. http://jens.ayton.se/code/keynaming/ – Jens Ayton May 02 '11 at 19:47
1

This looks promising:

+[ NSEvent addLocalMonitorForEventsMatchingMask:handler: ]

Seems to be new in 10.6 and sounds just like what you're looking for. More here:

http://developer.apple.com/library/mac/#documentation/Cocoa/Reference/ApplicationKit/Classes/NSEvent_Class/Reference/Reference.html%23//apple_ref/occ/clm/NSEvent/addLocalMonitorForEventsMatchingMask:handler:

nielsbot
  • 15,922
  • 4
  • 48
  • 73
  • No, this still does not treat modifier key events as regular key events (observe NSKeyDownMask and NSFlagsChangedMask). It appears to simply be a way to get notified of events like NSResponder does, without having to create an instance. – sarnesjo Apr 30 '11 at 22:40
  • This is basically a Cocoa version of Quartz event taps, which are mentioned in the question. – Peter Hosey Dec 28 '12 at 07:13