summaryrefslogtreecommitdiffstats
path: root/osdep/macosx_events.m
Commit message (Collapse)AuthorAgeFilesLines
* osx: add Apple Remote supportStefano Pigozzi2013-06-031-2/+59
| | | | | | | | | | | | | | | | | After killing the non functional AR support in c8fd9e5 I got much complaints so this adds AR support back in (and it works). I am using the HIDRemote class by Felix Schwarz and that part of the code is under the BSD license. I slightly modified it replacing [NSApplication sharedApplication] with NSApp. The code of the class is quite complex (probably because it had to deal with all the edge cases with IOKit) but it works nicely as a black box. In a later commit I'll remove the deprecation warnings caused by HIDRemote's usage of Gestalt. Check out `etc/input.conf` for the default bindings. Apple Remote functionality is automatically compiled in when cocoa is enabled. It can be disabled at runtime with the `--no-ar` option.
* osx: implement media keysStefano Pigozzi2013-06-031-0/+19
| | | | | | | | | | | | | | | Media keys are pretty handy if you use mpv as a music player (yes I'm one of those people that do). These are the bindings (which lead to the same behaviour as iTunes): * NX_KEYTYPE_PLAY -> MP_KEY_PLAY * NX_KEYTYPE_FAST -> MP_KEY_NEXT * NX_KEYTYPE_REWIND -> MP_KEY_PREV I just handled these ones as the volume one would be pretty invasive. I could maybe change it to increase the application's volume instead of system volume only when mpv is frontmost (iTunes does this), but some users would probably hate it.
* macosx_events: send all queued eventsStefano Pigozzi2013-06-031-2/+3
| | | | | Seeking feels a little faster or it may be self suggestion. There's really no reason to just send only one event at a time.
* osx: create macosx_events to deal with keyDown eventsStefano Pigozzi2013-06-031-0/+141
On OSX with Cocoa enabled keyDown events are now handled with addLocalMonitorForEventsMatchingMask:handler:. This allows to respond to events even when there is no VO initialized but the GUI is focused.