I am currently trying to get simple keyboard input on OSX, right now I am doing it through the Leopard HID Manager object and that generally works, but since that is pretty low level I am wondering if there is an API available that has some extra functionality build it like key repetition or Unicode support (since when I catch the events on HID I/O level I think I have to write all these fancy extras from scratch). I know carbon event handlers(NewEventHandlerUPP) are capable of that but I am pretty sure that they are deprecated since you can't find anything about them in the current OSX reference and I don't want to use anything deprecated, so I am wondering if there is any alternative I didn't come across during my search!
Thanks!
No.
At the Unicode level, the official API of receiving input is NSTextInputClient protocol in Objective-C, and the official API of processing input between the keyboard and the program is the Input Method Kit.
And you can never write a sufficiently fancy extra correctly from scratch. You need to get the user's setting of the international keyboard and modify the key obtained accordingly. And you can never write an input method from scratch which turns the raw key input to Chinese or Japanese ...
So, I think the sane choices are either
Just get the raw ASCII data from the keyboard and don't aim for more, or
Use Cocoa at least around the key input handling, to get additional features.
Related
I'm writing code specific for MountainLion so I want to try to avoid to use deprecated APIs.
I use FSFileOperationCreate to receive information about copy progress (kFSOperationBytesCompleteKey, kFSOperationThroughputKey, kFSOperationTotalBytesKey) but documentation says
Creates an object that represents an asynchronous file operation.
(Deprecated in OS X v10.8. At the Foundation layer, use
copyItemAtURL:toURL:error: instead. At the POSIX/BSD layer, use
copyfile(3) OS X Developer Tools Manual Page instead.)
Using copyItemAtURL:toURL:error and NSFileManagerDelegate seems impossible to obtain same informations.
How can I obtain same behaviour in 10.8 without rewriting code myself?
Does Apple know now it is simple awful to make same thing?
Might not be the answer you wish to hear[1], but wrap copyfile(3) in your own Obj-C wrapper. You should be able to calculate all you need using the callbacks, in particular the progress one. HTH.
[1] Quite a few APIs in this general area have been deprecated, and while some new APIs have been introduced they seem incomplete. Reasonable guess might be more is coming in 10.9...
I am about to implement simple keyboard and mouse input on osx for my engine. I want to abstract the implementation in more generic c++ classes like Keyboard and Mouse plus appropriate Listeners for portability. Anyways, I came across the Leopard HID Api (http://developer.apple.com/mac/library/technotes/tn2007/tn2187.html#TNTAG9000-SAMPLE_CODE_)which seems to be the right way to go for the osx implementation of these classes. Anyways, the examples of the HID are very complex and I can't really wrap my head around it as fast as I wished I could, so I was wondering if anybody has used it allready to get some basic mouse and keyboard input, or knows about some good examples/resources online.
Or Maybe even a totally different way to go?
thanks
DirectInput requires a lot of initialization functions and cetera to detect keyboard input, so what benefits are there to using it rather than the GetAsyncKeyState() function?
Courtesy of Wikipedia...
DirectInput and XInput have benefits over normal Win32 input events:
They enable an application to retrieve data from input devices even when the application is in the background.
They provide full support for any type of input device, as well as for force feedback.
Through action mapping, applications can retrieve input data without needing to know what kind of device is being used to generate it.
Basically DirectInput gives you more flexibility to move away from the keyboard. If the keyboard is all you ever plan on using then there is probably no harm in using GetAsyncKeyState()
Also see Should I use DirectInput or Windows message loop?
Microsoft seem to recommend just using windows messages to handle input data where possible now.
I am trying to port my screensaver from windows to mac and one of its features was reacting on system sound output. On windows it was easy using Direct Sound, but I can't find any example of capturing sound output on mac. Is it possible even possible without writing something like kernel extension? Using flash it is also very easy — it even gives computeSpectrum method to get raw data or even fft transformed data.
All programs that I have already found use Soundflower or their own kernel extension. But I don't think that asking to install separate program or using kernel extension is a good way.
One thing you can do, considering that Soundflower is open source, is take a look at how they did it. You can't copy & paste GPL code, but you can surely study the techniques used and create your own solution (point you in the right direction).
You won't find Apple being very helpful here. Sound capturing, in this manner, can be used for all kinds of nefarious purposes. I'm not even sure if Core Audio lets you do this without hacks. In any case, you have a working implementation of what you're trying to accomplish. I'd take advantage of it.
I'm not on my Mac right now, but I'm pretty sure that Quartz Composer has a patch for just this thing. Depending on what language you're writing your screen saver in, it may be fairly easy for you to port your code into a QC patch. Well... it probably won't be easy, but it may be doable.
I'm looking for application-wide access to raw keyboard events in OS X, either using the Cocoa or Carbon frameworks (or any of the underlying APIs, for that matter). I know that I can override NSApplication's sendEvent: to get raw keyboard information, but for the meta keys (command, control, alternate, shift, etc) don't show up as keystroke events. I'm looking for something analogous to Microsoft's DirectInput framework.
Thanks!
I think the equivalent to DirectInput is HID Manager. HID stands for "human interface device" and HID Manager (sometimes called HIDLib) is the low-level API to HIDs: keyboards, mice, and joysticks.
Leopard's got a new HID Manager API, documented in Technical Note TN2187. The pre-Leopard API is documented in HID Class Device Interface Guide. I wrote an Objecive-C wrapper around the older APIs, DDHidLib, which you may find useful. The Leopard API is much nicer. I'd use that directly, if you can.
The Core Graphics framework also has some useful functionality buried in it as part of the remote operation system. Look for CGRemoteOperation.h, and check out the Quartz Events reference.
You can use the Quartz Events system to install application-specific or system-wide "event taps", which let you monitor and inject keyboard and mouse events at a pretty low level. A few years ago there were some bugs with application-specific event taps, but they've hopefully been worked out by now.
I think the HID stuff is mostly for driver development, so if you're just looking for a tool for your application, HID is probably overkill.
NSResponder derived classes have a method -(void)flagsChanged: that gets called when meta-keys are held down.
You can use the RegisterHotKeyEvent Carbon function, I'm not sure if you can register for any of the meta keys explicitly though.
The blog post Program Global Hotkeys in Cocoa Easily explains how to do this.