RepoMirrors
/
mpv
mirror of https://github.com/mpv-player/mpv
1
0
Fork 0
Code Issues Releases Wiki Activity
mpv/osdep/macosx_application.h

50 lines
1.4 KiB
C
Raw Normal View History

OSX: use native Cocoa's event loop 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.
2013-02-23 17:28:22 +00:00
/*
* This file is part of mpv.
*
* mpv is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation; either version 2 of the License, or
* (at your option) any later version.
*
* mpv is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License along
* with mpv; if not, write to the Free Software Foundation, Inc.,
* 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
*/
#ifndef MPV_MACOSX_APPLICATION
#define MPV_MACOSX_APPLICATION
OSX: run native event loop in a separate thread 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.
2013-03-04 13:23:06 +00:00
typedef int (*mpv_main_fn)(int, char**);
OSX: use native Cocoa's event loop 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.
2013-02-23 17:28:22 +00:00
// Menu Keys identifing menu items
typedef enum {
MPM_H_SIZE,
MPM_N_SIZE,
MPM_D_SIZE,
MPM_MINIMIZE,
MPM_ZOOM,
} MPMenuKey;
OSX: run native event loop in a separate thread 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.
2013-03-04 13:23:06 +00:00
// multithreaded wrapper for mpv_main
int cocoa_main(mpv_main_fn mpv_main, int argc, char *argv[]);
OSX: use native Cocoa's event loop 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.
2013-02-23 17:28:22 +00:00
void cocoa_register_menu_item_action(MPMenuKey key, void* action);
// initializes Cocoa application
void init_cocoa_application(void);
void terminate_cocoa_application(void);
// Runs the Cocoa Main Event Loop
void cocoa_run_runloop(void);
OSX: run native event loop in a separate thread 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.
2013-03-04 13:23:06 +00:00
void cocoa_stop_runloop(void);
OSX: use native Cocoa's event loop 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.
2013-02-23 17:28:22 +00:00
void cocoa_post_fake_event(void);
void macosx_finder_args_preinit(int *argc, char ***argv);
#endif /* MPV_MACOSX_APPLICATION */