summaryrefslogtreecommitdiffstats
path: root/osdep/macosx_application_objc.h
Commit message (Collapse)AuthorAgeFilesLines
* cocoa-cb: remove pre-allocation of window, view and layerAkemi2018-06-121-1/+1
| | | | | | | | | | | the pre-allocation was needed because the layer allocated a opengl context async itself and we couldn't influence that. so we had to start the core after the context was actually allocated. furthermore a window, view and layer hierarchy had to be created so the layer would create a context. now, instead of relying on the layer to create a context we do this manually and re-use that context later when the layer wants to create one async itself.
* cocoa-cb: initial implementation via opengl-cb APIAkemi2018-02-121-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | this is meant to replace the old and not properly working vo_gpu/opengl cocoa backend in the future. the problems are various shortcomings of Apple's opengl implementation and buggy behaviour in certain circumstances that couldn't be properly worked around. there are also certain regressions on newer macOS versions from 10.11 onwards. - awful opengl performance with a none layer backed context - huge amount of dropped frames with an early context flush - flickering of system elements like the dock or volume indicator - double buffering not properly working with a none layer backed context - bad performance in fullscreen because of system optimisations all the problems were caused by using a normal opengl context, that seems somewhat abandoned by apple, and are fixed by using a layer backed opengl context instead. problems that couldn't be fixed could be properly worked around. this has all features our old backend has sans the wid embedding, the possibility to disable the automatic GPU switching and taking screenshots of the window content. the first was deemed unnecessary by me for now, since i just use the libmpv API that others can use anyway. second is technically not possible atm because we have to pre-allocate our opengl context at a time the config isn't read yet, so we can't get the needed property. third one is a bit tricky because of deadlocking and it needed to be in sync, hopefully i can work around that in the future. this also has at least one additional feature or eye-candy. a properly working fullscreen animation with the native fs. also since this is a direct port of the old backend of the parts that could be used, though with adaptions and improvements, this looks a lot cleaner and easier to understand. some credit goes to @pigoz for the initial swift build support which i could improve upon. Fixes: #5478, #5393, #5152, #5151, #4615, #4476, #3978, #3746, #3739, #2392, #2217
* osx: code cleanups and cosmetic fixesAkemi2018-01-201-1/+0
|
* osx: refactor menu bar creationAkemi2017-08-181-0/+1
| | | | | make the menu bar look more like a standard macOS menu bar, with all the standard menu items like About, Help, Open, etc.
* osx: move menu bar creation into its own fileAkemi2017-08-181-4/+3
|
* osx: change license of OSX and cocoa files to LGPLwm42017-06-241-7/+7
| | | | All authors of the current code have agreed.
* osx: initial Touch Bar supportAkemi2017-03-261-0/+5
|
* cocoa: always compile OSX application code with cocoawm42015-05-021-2/+0
| | | | | | | | | | | | | | This unbreaks compiling command line player and libmpv at the same time. The problem was that doing so silently disabled the OSX application thing - but the command line player can not use the vo_opengl Cocoa backend without it. The OSX application code is basically dead in libmpv, but it's not that much code anyway. If you want a mpv binary that does not create an OSX application singleton (and creates a menu etc.), you must disable cocoa completely, as cocoa can't be used anyway in this case.
* Update license headersMarcin Kurczewski2015-04-131-2/+1
| | | | Signed-off-by: wm4 <wm4@nowhere>
* cocoa: ignore first file open events from command lineStefano Pigozzi2014-12-071-0/+1
| | | similar to some of the code deleted in 685b8b7a but simpler
* cocoa: use --idle when running inside bundleStefano Pigozzi2014-12-061-2/+0
| | | | | Previously when using the bundle we used a custom bizarro thing to wait for events. Just use `--idle` and greatly simplify the code.
* cocoa: move handleFilesArray: to macosx_eventsFRAU KOUJIRO2014-08-061-1/+0
|
* cocoa: decouple events from application somewhatFRAU KOUJIRO2014-08-061-16/+0
|
* cocoa: handle files drag and drop on the player video viewStefano Pigozzi2014-01-041-0/+1
|
* cocoa: fix race condition with input context creationStefano Pigozzi2013-10-241-0/+1
| | | | | | | | | | This seems to be a problem only in OS X 10.9. I guess they improved the general speed of the Cocoa startup and suddenly mpv core takes more time than the Cocoa thread to initialize. Fixes #285 (hopefully!)
* cocoa: let the core handle key repeatsStefano Pigozzi2013-08-301-1/+1
| | | | | Report key down and key up modifiers to the core so that it can issue it's own key repeats (instead of relying on Cocoa's ones).
* macosx: remove platform specific input queueStefano Pigozzi2013-08-131-8/+0
| | | | | Since last commit the input queue in the core is thread safe, so there is no need for all this platform specific stuff anymore.
* cocoa_common: handle keyboard modifiers for mouse eventsStefano Pigozzi2013-07-211-0/+2
|
* cocoa: remove usage of mp_fifoStefano Pigozzi2013-07-031-1/+0
| | | | | | Update Cocoa parts to remove usage of the mp_fifo internal API to send events to the core and use the input context directly. This is to follow commits the work in commits 70a8079c and d603e73c.
* macosx_events: handle key modifiers with media keysStefano Pigozzi2013-06-061-1/+1
| | | | | | This was overlooked in the previous inplementation. Adding it required some refactoring of the `handleKeyDown:` method in order to extract common parts with `handleMediaKey:`.
* macosx_events: make remote property an instance variableStefano Pigozzi2013-06-051-2/+1
| | | | There was no reason for it to be public.
* osx: improve Media Keys supportStefano Pigozzi2013-06-041-1/+4
| | | | | | | | | | | | | | | | | | | | | | | This commit addresses some issues with the users had with the previous implementation in commit c39efb9. Here's the changes: * Use Quartz Event Taps to remove Media Key events mpv handles from the global OS X queue. This prevents conflicts with iTunes. I did this on the main thread since it is mostly idling. It's the playloop thread that actually does all the work so there is no danger of blocking the event tap callback. * Introduce `--no-media-keys` switch so that users can disable all of mpv's media key handling at runtime (some prefer iTunes for example). * Use mpv's bindings so that users can customize what the media keys do via input.conf. Current bindings are: MK_PLAY cycle pause MK_PREV playlist_prev MK_NEXT playlist_next An additional benefit of this implementation is that it is completly handled by the `macosx_events` file instead of `macosx_application` making the project organization more straightforward.
* osx: add Apple Remote supportStefano Pigozzi2013-06-031-1/+5
| | | | | | | | | | | | | | | | | 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/+1
| | | | | | | | | | | | | | | 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.
* osx: create macosx_events to deal with keyDown eventsStefano Pigozzi2013-06-031-1/+15
| | | | | | 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.
* OSX: run native event loop in a separate threadStefano Pigozzi2013-05-121-6/+0
| | | | | | | | | | | | | | This commit is a followup on the previous one and uses a solution I like more since it totally decouples the Cocoa code from mpv's core and tries to emulate a generic Cocoa application's lifecycle as much as possible without fighting the framework. mpv's main is executed in a pthread while the main thread runs the native cocoa event loop. All of the thread safety is mainly accomplished with additional logic in cocoa_common as to not increase complexity on the crossplatform parts of the code.
* OSX: use native Cocoa's event loopStefano Pigozzi2013-05-121-0/+40
Schedule mpv's playloop as a high frequency timer inside the main Cocoa event loop. This has the benefit to allow accessing menus as well as resizing the window without the playback being blocked and allows to remove countless hacks from the code that involved manually pumping the event loop as well simulating manually some of the Cocoa default behaviours. A huge improvement consists in removing NSApplicationLoad. This is a C function defined in the Cocoa header and implements a minimal OSX application under ther hood so that you can use the Cocoa GUI toolkit from C/C++ without having to respect the Cocoa standards in terms of application initialization. This was bad because the behaviour implemented by NSApplicationLoad was hard to customize and had several gotchas especially in the menu department. mpv was changed to be just a nib-less application. All the Cocoa part is still generated in code but the event handling is now not dissimilar to what is present in a stock Mac application. As a part of reviewing the initialization process, I also removed all of `osdep/macosx_finder_args`. The useful parts of the code were moved to `osdep/macosx_appication` which has the broaded responsibility of managing the full lifecycle of the Cocoa application. By consequence the `--enable-macosx-finder` configure switch was killed as well, as this feature is always enabled. Another change the users will notice is that when using a bundle the `--quiet` option will be inserted much earlier in the initializaion process. This results in mpv not spamming mpv.log anymore with all the initialization outputs.