| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
Add libdome_key_map.a to the "Link Binary With Libraries" Build Phase to
have our Rust code linked with DomeKey.
|
|
Make a sub-make target for the Rust library. We'll want to make this a
dependency of the regular DomeKey `build` target.
|
|
|
|
This is the Rust library part of the application, which will get linked
into DomeKey as a static library.
|
|
Planning on using this to set up build a dependency on the Rust project.
|
|
Replace the `keyCodeForChar:` placeholder function I had created earlier
with the new `charToKeyCode:` from `char_to_key_code.m`.
|
|
Make a corresponding header file for `char_to_key_code.m`. This enables
us to include those functions in other source files.
|
|
Fix the following warning from Xcode's analyzer:
char_to_key_code.m:62:49: Implicit conversion loses integer
precision: 'size_t' (aka 'unsigned long') to 'int'
Since `NSNumber` `numberWithInt` takes an `int`, change `i` to `int`.
|
|
The TIS functions etc. are in Carbon, which needs to be imported.
|
|
This file includes functions for getting a `CGKeyCode` from a character
reference.
Copied from Stack Overflow by Théo Winterhalter.
|
|
This as yet untested method will be responsible for simulating a key
press given a single-character string corresponding to the glyph of the
key to be pressed.
It relies on `keyCodeForChar:` to get the `CGKeyCode` corresponding to
the glyph, a method which is currently just a placeholder.
|
|
A new class that will know how to simulate key presses in order to
handle macros.
|
|
As alluded to in 8b94ca51e7ef431c476d1c500f36157a976186f0, since we
cancel the `performSelector` in `handleDeadKey:`, this method doesn't
"maybe" anything, it should always run the action.
|
|
We need a way to listen for multiple presses of the headphone buttons.
Once a timeout has been reached, the recorded button presses that
happened within the space of the timeout will be those used for
performing an associated action.
We add an enum for headphone buttons to give them an easy name to refer
to.
The default timeout between button presses before an action gets
executed is 1000 milliseconds. This will be customisable later with a
configuration file.
Already pressed "dead" keys within the timeout are stored in
`_key_buffer`. This buffer gets cleared when we run an action. I you've
pressed a headphone button key, we always try to run an action, so this
will always get cleared, even if no mapping action is found.
I decided to start `_key_buffer` with a capacity of 5 at random because
that seemed like more than enough button presses for a single mapping.
handleDeadKey::
- In order to append a `HeadphoneButton` from our enum, I needed to
convert it to an `id` type because `NSArray` doesn't allow anything
else.
- Call `maybeRunAction` with our timeout. Before doing this, make sure
we cancel any previous delayed calls to `maybeRunAction` because they
might be executed before the most recent headphone button press and
thus run the wrong action. Cancelling enables us to only run the
action once the timeout has elapsed after the most recent headphone
button press.
maybeRunAction:
- Just log the headphone button presses for now.
- Remove all presses from `_key_buffer` so to make way for a new key
mapping.
- I'm now thinking I should rename this method to remove the `maybe`.
Since the `performSelector` gets cancelled outside of this method, the
"maybe" doesn't make sense to me here any more.
|
|
Using my previous `NSLog`s, the `usageId`s came out to be 205, 233, 234.
Converted these to hex and looked for corresponding constants in
`/System/Library/Frameworks/IOKit.framework/Versions/A/Headers/hid/IOHIDUsageTables.h`.
Use these constants to figure out which button was presed. Will have to
test other headphones. I'm worried the numbers may change for different
headphones.
Added a `KeyPress` enum that's a lot easier to understand than the
`upOrDown` `BOOL`, whose meaning I completely didn't get until I looked
at the `NSLog` output I had before.
|
|
What does it mean?
|
|
Previously the `setListenInExclusiveMode:` call did appear to work,
disabling the normal functioning of the headphone buttons. But my
`NSLog`s in `ddhidAppleMikey:press:upOrDown:` didn't get printed, the
method having not been called.
Since all the other applications I found using DDHidLib were GUI apps
using `NSApplication`, I decided to take this approach here. Set up the
`NSApplication` in `main.c` and added a new `AppDelegate` class.
It seems like the reference to my `HeadphoneKey` instance wasn't getting
retained or something. When I moved the:
HeadphoneKey *h = [[HeadphoneKey alloc] init];
line into `AppDelegate`'s `applicationDidFinishLaunching:`, nothing
changed. However, when I moved all code from `HeadphoneKey` into
`AppDelegate`, my `ddhidAppleMikey:press:upOrDown:` method _did_ get
called.
At that point, it was logical to try adding a `HeadphoneKey` instance
variable and `init`ing into that variable. As a result, we now have a
working `ddhidAppleMikey:press:upOrDown:` delegate method that correctly
logs the headphone key events!
Here are the reference applications I looked at using DDHidLib, found
using a simple GitHub search:
- https://github.com/radiant-player/radiant-player-mac/pull/450/files
- https://github.com/7hil/mac_ear_control/blob/8859ed554517ce798b8ae7c2d0e78610b9994300/mac_ear_control/AppDelegate.m
- https://github.com/7hil/mac_ear_control/blob/8859ed554517ce798b8ae7c2d0e78610b9994300/mac_ear_control/AppDelegate.m
- https://github.com/schrekia/beardedspice-enhanced/blob/a9b78c0dbae6bca2cb0d2ecc362e4b7fe5b02129/BeardedSpiceControllers/BSCService.m
- https://github.com/beardedspice/beardedspice/blob/8e1aea5bda68395e6b0d866bca9289a2a5ba40ed/BeardedSpiceControllers/BSCService.m
- https://github.com/beardedspice/beardedspice/blob/8e1aea5bda68395e6b0d866bca9289a2a5ba40ed/BeardedSpiceControllers/BSCService.m
- https://github.com/BarakaAka1Only/radiant-player-mac-BarakaLyrics/blob/1ce889bbb80f081209aff7936a329a3b426462e9/radiant-player-mac/AppDelegate.m
- https://github.com/zsszatmari/MagicKeys/blob/210015d5da876cd7bb1daf73efa3c775c18e7973/MagicKeys-Agent/SPMediaKeyTap.m
Thanks immensely this Cocoa With Love article from Matt Gallagher, which
was invaluable in showing me how to create a minimal Cocoa application
without needing a nib, Info.plist, or even application bundle (instead
putting everything in a single executable, making it easier to
distribute this as a command-line application with a built-in daemon):
https://www.cocoawithlove.com/2010/09/minimalist-cocoa-programming.html
|
|
Try to set up a listener for headphone button events. Doesn't appear to
work. The initialiser is called, but the delegate method doesn't appear
to be. I'm not seeing any of those log messages.
Followed an example from here:
https://github.com/radiant-player/radiant-player-mac/pull/450/files
Not sure what I'm doing wrong yet, but decided I should commit what I
have since I can't figure it out right now.
|
|
Since the framework is external, we can't link it directly as it's a
third-party library. As such, it would be separate from our executable.
Instead, link against the static DDHidLib library so that it gets
bundled into the executable.
|
|
This will be our delegate for the DDHID key listener.
|
|
|
|
This will hopefully make it easier to interface with `IOHIDLib` and get
events from headphone buttons.
|
|
Taken from https://www.gitignore.io/api/objective-c with modifications.
Cleaned up the comments and got rid of things I didn't think were
necesary.
|
|
|
