jp9000
/
obs-studio
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
obs-studio/libobs/obs-module.h

176 lines
6.9 KiB
C
Raw Normal View History

first commit
2013-09-30 19:37:13 -07:00
/******************************************************************************
Revamp API and start using doxygen The API used to be designed in such a way to where it would expect exports for each individual source/output/encoder/etc. You would export functions for each and it would automatically load those functions based on a specific naming scheme from the module. The idea behind this was that I wanted to limit the usage of structures in the API so only functions could be used. It was an interesting idea in theory, but this idea turned out to be flawed in a number of ways: 1.) Requiring exports to create sources/outputs/encoders/etc meant that you could not create them by any other means, which meant that things like faruton's .net plugin would become difficult. 2.) Export function declarations could not be checked, therefore if you created a function with the wrong parameters and parameter types, the compiler wouldn't know how to check for that. 3.) Required overly complex load functions in libobs just to handle it. It makes much more sense to just have a load function that you call manually. Complexity is the bane of all good programs. 4.) It required that you have functions of specific names, which looked and felt somewhat unsightly. So, to fix these issues, I replaced it with a more commonly used API scheme, seen commonly in places like kernels and typical C libraries with abstraction. You simply create a structure that contains the callback definitions, and you pass it to a function to register that definition (such as obs_register_source), which you call in the obs_module_load of the module. It will also automatically check the structure size and ensure that it only loads the required values if the structure happened to add new values in an API change. The "main" source file for each module must include obs-module.h, and must use OBS_DECLARE_MODULE() within that source file. Also, started writing some doxygen documentation in to the main library headers. Will add more detailed documentation as I go.
2014-02-12 07:04:50 -08:00
Copyright (C) 2014 by Hugh Bailey <obs.jim@gmail.com>
first commit
2013-09-30 19:37:13 -07:00
This program is free software: you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
With the permission of my fellow contributors, I'm switching obs-studio back to GPL v2+ to prevent issues between this project and the original OBS project, and for personal reasons to avoid legal ambiguity (not political reasons, I admittedly would prefer GPL v3+)
2013-12-02 21:24:38 -08:00
the Free Software Foundation, either version 2 of the License, or
first commit
2013-09-30 19:37:13 -07:00
(at your option) any later version.
This program 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 this program. If not, see <http://www.gnu.org/licenses/>.
******************************************************************************/
modernize header guards to #pragma once
2013-10-14 04:21:15 -07:00
#pragma once
first commit
2013-09-30 19:37:13 -07:00
Revamp API and start using doxygen The API used to be designed in such a way to where it would expect exports for each individual source/output/encoder/etc. You would export functions for each and it would automatically load those functions based on a specific naming scheme from the module. The idea behind this was that I wanted to limit the usage of structures in the API so only functions could be used. It was an interesting idea in theory, but this idea turned out to be flawed in a number of ways: 1.) Requiring exports to create sources/outputs/encoders/etc meant that you could not create them by any other means, which meant that things like faruton's .net plugin would become difficult. 2.) Export function declarations could not be checked, therefore if you created a function with the wrong parameters and parameter types, the compiler wouldn't know how to check for that. 3.) Required overly complex load functions in libobs just to handle it. It makes much more sense to just have a load function that you call manually. Complexity is the bane of all good programs. 4.) It required that you have functions of specific names, which looked and felt somewhat unsightly. So, to fix these issues, I replaced it with a more commonly used API scheme, seen commonly in places like kernels and typical C libraries with abstraction. You simply create a structure that contains the callback definitions, and you pass it to a function to register that definition (such as obs_register_source), which you call in the obs_module_load of the module. It will also automatically check the structure size and ensure that it only loads the required values if the structure happened to add new values in an API change. The "main" source file for each module must include obs-module.h, and must use OBS_DECLARE_MODULE() within that source file. Also, started writing some doxygen documentation in to the main library headers. Will add more detailed documentation as I go.
2014-02-12 07:04:50 -08:00
#include "obs.h"
first commit
2013-09-30 19:37:13 -07:00
Revamp API and start using doxygen The API used to be designed in such a way to where it would expect exports for each individual source/output/encoder/etc. You would export functions for each and it would automatically load those functions based on a specific naming scheme from the module. The idea behind this was that I wanted to limit the usage of structures in the API so only functions could be used. It was an interesting idea in theory, but this idea turned out to be flawed in a number of ways: 1.) Requiring exports to create sources/outputs/encoders/etc meant that you could not create them by any other means, which meant that things like faruton's .net plugin would become difficult. 2.) Export function declarations could not be checked, therefore if you created a function with the wrong parameters and parameter types, the compiler wouldn't know how to check for that. 3.) Required overly complex load functions in libobs just to handle it. It makes much more sense to just have a load function that you call manually. Complexity is the bane of all good programs. 4.) It required that you have functions of specific names, which looked and felt somewhat unsightly. So, to fix these issues, I replaced it with a more commonly used API scheme, seen commonly in places like kernels and typical C libraries with abstraction. You simply create a structure that contains the callback definitions, and you pass it to a function to register that definition (such as obs_register_source), which you call in the obs_module_load of the module. It will also automatically check the structure size and ensure that it only loads the required values if the structure happened to add new values in an API change. The "main" source file for each module must include obs-module.h, and must use OBS_DECLARE_MODULE() within that source file. Also, started writing some doxygen documentation in to the main library headers. Will add more detailed documentation as I go.
2014-02-12 07:04:50 -08:00
#ifdef __cplusplus
#define MODULE_EXPORT extern "C" EXPORT
Use C externs for obs-module.h This allows inter-sharing of functions such as obs_module_text among both C and C++ files
2014-08-29 11:19:58 -07:00
#define MODULE_EXTERN extern "C"
Revamp API and start using doxygen The API used to be designed in such a way to where it would expect exports for each individual source/output/encoder/etc. You would export functions for each and it would automatically load those functions based on a specific naming scheme from the module. The idea behind this was that I wanted to limit the usage of structures in the API so only functions could be used. It was an interesting idea in theory, but this idea turned out to be flawed in a number of ways: 1.) Requiring exports to create sources/outputs/encoders/etc meant that you could not create them by any other means, which meant that things like faruton's .net plugin would become difficult. 2.) Export function declarations could not be checked, therefore if you created a function with the wrong parameters and parameter types, the compiler wouldn't know how to check for that. 3.) Required overly complex load functions in libobs just to handle it. It makes much more sense to just have a load function that you call manually. Complexity is the bane of all good programs. 4.) It required that you have functions of specific names, which looked and felt somewhat unsightly. So, to fix these issues, I replaced it with a more commonly used API scheme, seen commonly in places like kernels and typical C libraries with abstraction. You simply create a structure that contains the callback definitions, and you pass it to a function to register that definition (such as obs_register_source), which you call in the obs_module_load of the module. It will also automatically check the structure size and ensure that it only loads the required values if the structure happened to add new values in an API change. The "main" source file for each module must include obs-module.h, and must use OBS_DECLARE_MODULE() within that source file. Also, started writing some doxygen documentation in to the main library headers. Will add more detailed documentation as I go.
2014-02-12 07:04:50 -08:00
#else
#define MODULE_EXPORT EXPORT
Use C externs for obs-module.h This allows inter-sharing of functions such as obs_module_text among both C and C++ files
2014-08-29 11:19:58 -07:00
#define MODULE_EXTERN extern
Revamp API and start using doxygen The API used to be designed in such a way to where it would expect exports for each individual source/output/encoder/etc. You would export functions for each and it would automatically load those functions based on a specific naming scheme from the module. The idea behind this was that I wanted to limit the usage of structures in the API so only functions could be used. It was an interesting idea in theory, but this idea turned out to be flawed in a number of ways: 1.) Requiring exports to create sources/outputs/encoders/etc meant that you could not create them by any other means, which meant that things like faruton's .net plugin would become difficult. 2.) Export function declarations could not be checked, therefore if you created a function with the wrong parameters and parameter types, the compiler wouldn't know how to check for that. 3.) Required overly complex load functions in libobs just to handle it. It makes much more sense to just have a load function that you call manually. Complexity is the bane of all good programs. 4.) It required that you have functions of specific names, which looked and felt somewhat unsightly. So, to fix these issues, I replaced it with a more commonly used API scheme, seen commonly in places like kernels and typical C libraries with abstraction. You simply create a structure that contains the callback definitions, and you pass it to a function to register that definition (such as obs_register_source), which you call in the obs_module_load of the module. It will also automatically check the structure size and ensure that it only loads the required values if the structure happened to add new values in an API change. The "main" source file for each module must include obs-module.h, and must use OBS_DECLARE_MODULE() within that source file. Also, started writing some doxygen documentation in to the main library headers. Will add more detailed documentation as I go.
2014-02-12 07:04:50 -08:00
#endif
first commit
2013-09-30 19:37:13 -07:00
Revamp API and start using doxygen The API used to be designed in such a way to where it would expect exports for each individual source/output/encoder/etc. You would export functions for each and it would automatically load those functions based on a specific naming scheme from the module. The idea behind this was that I wanted to limit the usage of structures in the API so only functions could be used. It was an interesting idea in theory, but this idea turned out to be flawed in a number of ways: 1.) Requiring exports to create sources/outputs/encoders/etc meant that you could not create them by any other means, which meant that things like faruton's .net plugin would become difficult. 2.) Export function declarations could not be checked, therefore if you created a function with the wrong parameters and parameter types, the compiler wouldn't know how to check for that. 3.) Required overly complex load functions in libobs just to handle it. It makes much more sense to just have a load function that you call manually. Complexity is the bane of all good programs. 4.) It required that you have functions of specific names, which looked and felt somewhat unsightly. So, to fix these issues, I replaced it with a more commonly used API scheme, seen commonly in places like kernels and typical C libraries with abstraction. You simply create a structure that contains the callback definitions, and you pass it to a function to register that definition (such as obs_register_source), which you call in the obs_module_load of the module. It will also automatically check the structure size and ensure that it only loads the required values if the structure happened to add new values in an API change. The "main" source file for each module must include obs-module.h, and must use OBS_DECLARE_MODULE() within that source file. Also, started writing some doxygen documentation in to the main library headers. Will add more detailed documentation as I go.
2014-02-12 07:04:50 -08:00
/**
* @file
Some documentation improvements in obs-module.h
2014-10-12 10:53:03 -07:00
* @brief This file is used by modules for module declaration and module
* exports.
*
* @page modules_page Modules
* @brief Modules or plugins are libraries that can be loaded by libobs and
* subsequently interact with it.
*
* @section modules_overview_sec Overview
*
* Modules can provide a wide range of functionality to libobs, they for example
* can feed captured audio or video to libobs, or interface with an encoder to
* provide some codec to libobs.
*
* @section modules_basic_sec Creating a basic module
*
* In order to create a module for libobs you will need to build a shared
* library that implements a basic interface for libobs to interact with.
* The following code would create a simple source plugin without localization:
*
@code
#include <obs-module.h>
OBS_DECLARE_MODULE()
extern struct obs_source_info my_source;
bool obs_module_load(void)
{
obs_register_source(&my_source);
return true;
}
@endcode
*
* If you want to enable localization, you will need to also use the
* @ref OBS_MODULE_USE_DEFAULT_LOCALE() macro.
*
* Other module types:
* - @ref obs_register_encoder()
* - @ref obs_register_service()
* - @ref obs_register_output()
Revamp API and start using doxygen The API used to be designed in such a way to where it would expect exports for each individual source/output/encoder/etc. You would export functions for each and it would automatically load those functions based on a specific naming scheme from the module. The idea behind this was that I wanted to limit the usage of structures in the API so only functions could be used. It was an interesting idea in theory, but this idea turned out to be flawed in a number of ways: 1.) Requiring exports to create sources/outputs/encoders/etc meant that you could not create them by any other means, which meant that things like faruton's .net plugin would become difficult. 2.) Export function declarations could not be checked, therefore if you created a function with the wrong parameters and parameter types, the compiler wouldn't know how to check for that. 3.) Required overly complex load functions in libobs just to handle it. It makes much more sense to just have a load function that you call manually. Complexity is the bane of all good programs. 4.) It required that you have functions of specific names, which looked and felt somewhat unsightly. So, to fix these issues, I replaced it with a more commonly used API scheme, seen commonly in places like kernels and typical C libraries with abstraction. You simply create a structure that contains the callback definitions, and you pass it to a function to register that definition (such as obs_register_source), which you call in the obs_module_load of the module. It will also automatically check the structure size and ensure that it only loads the required values if the structure happened to add new values in an API change. The "main" source file for each module must include obs-module.h, and must use OBS_DECLARE_MODULE() within that source file. Also, started writing some doxygen documentation in to the main library headers. Will add more detailed documentation as I go.
2014-02-12 07:04:50 -08:00
*
*/
/** Required: Declares a libobs module. */
clang-format: Apply formatting Code submissions have continually suffered from formatting inconsistencies that constantly have to be addressed. Using clang-format simplifies this by making code formatting more consistent, and allows automation of the code formatting so that maintainers can focus more on the code itself instead of code formatting.
2019-06-22 22:13:45 -07:00
#define OBS_DECLARE_MODULE() \
static obs_module_t *obs_module_pointer; \
MODULE_EXPORT void obs_module_set_pointer(obs_module_t *module); \
void obs_module_set_pointer(obs_module_t *module) \
{ \
obs_module_pointer = module; \
} \
obs_module_t *obs_current_module(void) { return obs_module_pointer; } \
MODULE_EXPORT uint32_t obs_module_ver(void); \
uint32_t obs_module_ver(void) { return LIBOBS_API_VER; }
Revamp API and start using doxygen The API used to be designed in such a way to where it would expect exports for each individual source/output/encoder/etc. You would export functions for each and it would automatically load those functions based on a specific naming scheme from the module. The idea behind this was that I wanted to limit the usage of structures in the API so only functions could be used. It was an interesting idea in theory, but this idea turned out to be flawed in a number of ways: 1.) Requiring exports to create sources/outputs/encoders/etc meant that you could not create them by any other means, which meant that things like faruton's .net plugin would become difficult. 2.) Export function declarations could not be checked, therefore if you created a function with the wrong parameters and parameter types, the compiler wouldn't know how to check for that. 3.) Required overly complex load functions in libobs just to handle it. It makes much more sense to just have a load function that you call manually. Complexity is the bane of all good programs. 4.) It required that you have functions of specific names, which looked and felt somewhat unsightly. So, to fix these issues, I replaced it with a more commonly used API scheme, seen commonly in places like kernels and typical C libraries with abstraction. You simply create a structure that contains the callback definitions, and you pass it to a function to register that definition (such as obs_register_source), which you call in the obs_module_load of the module. It will also automatically check the structure size and ensure that it only loads the required values if the structure happened to add new values in an API change. The "main" source file for each module must include obs-module.h, and must use OBS_DECLARE_MODULE() within that source file. Also, started writing some doxygen documentation in to the main library headers. Will add more detailed documentation as I go.
2014-02-12 07:04:50 -08:00
/**
* Required: Called when the module is loaded. Use this function to load all
* the sources/encoders/outputs/services for your module, or anything else that
* may need loading.
*
* @return Return true to continue loading the module, otherwise
Fix various typos across multiple modules
2017-03-19 04:35:51 -07:00
* false to indicate failure and unload the module
Revamp API and start using doxygen The API used to be designed in such a way to where it would expect exports for each individual source/output/encoder/etc. You would export functions for each and it would automatically load those functions based on a specific naming scheme from the module. The idea behind this was that I wanted to limit the usage of structures in the API so only functions could be used. It was an interesting idea in theory, but this idea turned out to be flawed in a number of ways: 1.) Requiring exports to create sources/outputs/encoders/etc meant that you could not create them by any other means, which meant that things like faruton's .net plugin would become difficult. 2.) Export function declarations could not be checked, therefore if you created a function with the wrong parameters and parameter types, the compiler wouldn't know how to check for that. 3.) Required overly complex load functions in libobs just to handle it. It makes much more sense to just have a load function that you call manually. Complexity is the bane of all good programs. 4.) It required that you have functions of specific names, which looked and felt somewhat unsightly. So, to fix these issues, I replaced it with a more commonly used API scheme, seen commonly in places like kernels and typical C libraries with abstraction. You simply create a structure that contains the callback definitions, and you pass it to a function to register that definition (such as obs_register_source), which you call in the obs_module_load of the module. It will also automatically check the structure size and ensure that it only loads the required values if the structure happened to add new values in an API change. The "main" source file for each module must include obs-module.h, and must use OBS_DECLARE_MODULE() within that source file. Also, started writing some doxygen documentation in to the main library headers. Will add more detailed documentation as I go.
2014-02-12 07:04:50 -08:00
*/
Remove version parameter from obs_module_load Replaced by obs_get_version() API
2014-07-27 12:42:43 -07:00
MODULE_EXPORT bool obs_module_load(void);
Revamp API and start using doxygen The API used to be designed in such a way to where it would expect exports for each individual source/output/encoder/etc. You would export functions for each and it would automatically load those functions based on a specific naming scheme from the module. The idea behind this was that I wanted to limit the usage of structures in the API so only functions could be used. It was an interesting idea in theory, but this idea turned out to be flawed in a number of ways: 1.) Requiring exports to create sources/outputs/encoders/etc meant that you could not create them by any other means, which meant that things like faruton's .net plugin would become difficult. 2.) Export function declarations could not be checked, therefore if you created a function with the wrong parameters and parameter types, the compiler wouldn't know how to check for that. 3.) Required overly complex load functions in libobs just to handle it. It makes much more sense to just have a load function that you call manually. Complexity is the bane of all good programs. 4.) It required that you have functions of specific names, which looked and felt somewhat unsightly. So, to fix these issues, I replaced it with a more commonly used API scheme, seen commonly in places like kernels and typical C libraries with abstraction. You simply create a structure that contains the callback definitions, and you pass it to a function to register that definition (such as obs_register_source), which you call in the obs_module_load of the module. It will also automatically check the structure size and ensure that it only loads the required values if the structure happened to add new values in an API change. The "main" source file for each module must include obs-module.h, and must use OBS_DECLARE_MODULE() within that source file. Also, started writing some doxygen documentation in to the main library headers. Will add more detailed documentation as I go.
2014-02-12 07:04:50 -08:00
/** Optional: Called when the module is unloaded. */
MODULE_EXPORT void obs_module_unload(void);
libobs: Add post-load module callback This allows the ability for certain types of modules (particularly scripting-related modules) to initialize extra data when all other modules have loaded. Because front-ends may wish to have custom handling for loading modules, the front-end must manually call obs_post_load_modules after it has completed loading all plug-in modules. Closes jp9000/obs-studio#965
2017-07-14 20:26:53 -07:00
/** Optional: Called when all modules have finished loading */
MODULE_EXPORT void obs_module_post_load(void);
Add module callbacks for loading locale data The module callback obs_module_set_locale will be called after loading the module, and any time the locale is manually changed via core API. When this function is called, the module is expected to load new text lookup values for all the text it uses based upon the current locale.
2014-06-25 00:22:54 -07:00
/** Called to set the current locale data for the module. */
MODULE_EXPORT void obs_module_set_locale(const char *locale);
(API Change) Refactor module handling Changed API: - char *obs_find_plugin_file(const char *sub_path); Changed to: char *obs_module_file(const char *file); Cahnge it so you no longer need to specify a sub-path such as: obs_find_plugin_file("module_name/file.ext") Instead, now automatically handle the module data path so all you need to do is: obs_module_file("file.ext") - int obs_load_module(const char *name); Changed to: int obs_open_module(obs_module_t *module, const char *path, const char *data_path); bool obs_init_module(obs_module_t module); Change the module loading API so that if the front-end chooses, it can load modules directly from a specified path, and associate a data directory with it on the spot. The module will not be initialized immediately; obs_init_module must be called on the module pointer in order to fully initialize the module. This is done so a module can be disabled by the front-end if the it so chooses. New API: - void obs_add_module_path(const char *bin, const char *data); These functions allow you to specify new module search paths to add, and allow you to search through them, or optionally just load all modules from them. If the string %module% is included, it will replace it with the module's name when that string is used as a lookup. Data paths are now directly added to the module's internal storage structure, and when obs_find_module_file is used, it will look up the pointer to the obs_module structure and get its data directory that way. Example: obs_add_module_path("/opt/obs/my-modules/%module%/bin", "/opt/obs/my-modules/%module%/data"); This would cause it to additionally look for the binary of a hypthetical module named "foo" at /opt/obs/my-modules/foo/bin/foo.so (or libfoo.so), and then look for the data in /opt/obs/my-modules/foo/data. This gives the front-end more flexibility for handling third-party plugin modules, or handling all plugin modules in a custom way. - void obs_find_modules(obs_find_module_callback_t callback, void *param); This searches the existing paths for modules and calls the callback function when any are found. Useful for plugin management and custom handling of the paths by the front-end if desired. - void obs_load_all_modules(void); Search through the paths and both loads and initializes all modules automatically without custom handling. - void obs_enum_modules(obs_enum_module_callback_t callback, void *param); Enumerates currently opened modules.
2014-07-27 12:00:11 -07:00
/** Called to free the current locale data for the module. */
MODULE_EXPORT void obs_module_free_locale(void);
/** Optional: Use this macro in a module to use default locale handling. */
clang-format: Apply formatting Code submissions have continually suffered from formatting inconsistencies that constantly have to be addressed. Using clang-format simplifies this by making code formatting more consistent, and allows automation of the code formatting so that maintainers can focus more on the code itself instead of code formatting.
2019-06-22 22:13:45 -07:00
#define OBS_MODULE_USE_DEFAULT_LOCALE(module_name, default_locale) \
lookup_t *obs_module_lookup = NULL; \
const char *obs_module_text(const char *val) \
{ \
const char *out = val; \
text_lookup_getstr(obs_module_lookup, val, &out); \
return out; \
} \
bool obs_module_get_string(const char *val, const char **out) \
{ \
libobs: Add obs_module_get_string helper function Allows getting a translated string for the current module, returning false if no string available.
2016-09-01 00:39:37 -07:00
return text_lookup_getstr(obs_module_lookup, val, out); \
clang-format: Apply formatting Code submissions have continually suffered from formatting inconsistencies that constantly have to be addressed. Using clang-format simplifies this by making code formatting more consistent, and allows automation of the code formatting so that maintainers can focus more on the code itself instead of code formatting.
2019-06-22 22:13:45 -07:00
} \
void obs_module_set_locale(const char *locale) \
{ \
if (obs_module_lookup) \
text_lookup_destroy(obs_module_lookup); \
obs_module_lookup = obs_module_load_locale( \
obs_current_module(), default_locale, locale); \
} \
void obs_module_free_locale(void) \
{ \
text_lookup_destroy(obs_module_lookup); \
libobs: Fix formatting
2019-07-12 11:48:12 -07:00
obs_module_lookup = NULL; \
libobs: Add macro for default module locale These macros are used as easy helper functions to load/unload module locale that's based upon the text_lookup system. You simple place the OBS_MODULE_USE_DEFAULT_LOCALE macro once in the module, call OBS_MODULE_FREE_DEFAULT LOCALE in obs_module_unload, and then call obs_module_text anywhere in your module where you need to look up text. By default, it will look for a locale directory in your module's data directory, and look for language files within it (INI locale format)
2014-07-09 21:32:54 -07:00
}
/** Helper function for looking up locale if default locale handler was used */
Use C externs for obs-module.h This allows inter-sharing of functions such as obs_module_text among both C and C++ files
2014-08-29 11:19:58 -07:00
MODULE_EXTERN const char *obs_module_text(const char *lookup_string);
libobs: Add macro for default module locale These macros are used as easy helper functions to load/unload module locale that's based upon the text_lookup system. You simple place the OBS_MODULE_USE_DEFAULT_LOCALE macro once in the module, call OBS_MODULE_FREE_DEFAULT LOCALE in obs_module_unload, and then call obs_module_text anywhere in your module where you need to look up text. By default, it will look for a locale directory in your module's data directory, and look for language files within it (INI locale format)
2014-07-09 21:32:54 -07:00
libobs: Add obs_module_get_string helper function Allows getting a translated string for the current module, returning false if no string available.
2016-09-01 00:39:37 -07:00
/** Helper function for looking up locale if default locale handler was used,
* returns true if text found, otherwise false */
libobs: Add functions to get locale text from modules Useful for sharing translated text from modules with the frontend. This is technically already done via properties, but it would be nice to just be able to explicitly look up locale text directly rather than have to go through properties.
2020-08-08 10:01:17 -07:00
MODULE_EXPORT bool obs_module_get_string(const char *lookup_string,
clang-format: Apply formatting Code submissions have continually suffered from formatting inconsistencies that constantly have to be addressed. Using clang-format simplifies this by making code formatting more consistent, and allows automation of the code formatting so that maintainers can focus more on the code itself instead of code formatting.
2019-06-22 22:13:45 -07:00
const char **translated_string);
libobs: Add obs_module_get_string helper function Allows getting a translated string for the current module, returning false if no string available.
2016-09-01 00:39:37 -07:00
(API Change) Refactor module handling Changed API: - char *obs_find_plugin_file(const char *sub_path); Changed to: char *obs_module_file(const char *file); Cahnge it so you no longer need to specify a sub-path such as: obs_find_plugin_file("module_name/file.ext") Instead, now automatically handle the module data path so all you need to do is: obs_module_file("file.ext") - int obs_load_module(const char *name); Changed to: int obs_open_module(obs_module_t *module, const char *path, const char *data_path); bool obs_init_module(obs_module_t module); Change the module loading API so that if the front-end chooses, it can load modules directly from a specified path, and associate a data directory with it on the spot. The module will not be initialized immediately; obs_init_module must be called on the module pointer in order to fully initialize the module. This is done so a module can be disabled by the front-end if the it so chooses. New API: - void obs_add_module_path(const char *bin, const char *data); These functions allow you to specify new module search paths to add, and allow you to search through them, or optionally just load all modules from them. If the string %module% is included, it will replace it with the module's name when that string is used as a lookup. Data paths are now directly added to the module's internal storage structure, and when obs_find_module_file is used, it will look up the pointer to the obs_module structure and get its data directory that way. Example: obs_add_module_path("/opt/obs/my-modules/%module%/bin", "/opt/obs/my-modules/%module%/data"); This would cause it to additionally look for the binary of a hypthetical module named "foo" at /opt/obs/my-modules/foo/bin/foo.so (or libfoo.so), and then look for the data in /opt/obs/my-modules/foo/data. This gives the front-end more flexibility for handling third-party plugin modules, or handling all plugin modules in a custom way. - void obs_find_modules(obs_find_module_callback_t callback, void *param); This searches the existing paths for modules and calls the callback function when any are found. Useful for plugin management and custom handling of the paths by the front-end if desired. - void obs_load_all_modules(void); Search through the paths and both loads and initializes all modules automatically without custom handling. - void obs_enum_modules(obs_enum_module_callback_t callback, void *param); Enumerates currently opened modules.
2014-07-27 12:00:11 -07:00
/** Helper function that returns the current module */
(API Change) Remove pointers from all typedefs Typedef pointers are unsafe. If you do: typedef struct bla *bla_t; then you cannot use it as a constant, such as: const bla_t, because that constant will be to the pointer itself rather than to the underlying data. I admit this was a fundamental mistake that must be corrected. All typedefs that were pointer types will now have their pointers removed from the type itself, and the pointers will be used when they are actually used as variables/parameters/returns instead. This does not break ABI though, which is pretty nice.
2014-09-25 17:44:05 -07:00
MODULE_EXTERN obs_module_t *obs_current_module(void);
(API Change) Refactor module handling Changed API: - char *obs_find_plugin_file(const char *sub_path); Changed to: char *obs_module_file(const char *file); Cahnge it so you no longer need to specify a sub-path such as: obs_find_plugin_file("module_name/file.ext") Instead, now automatically handle the module data path so all you need to do is: obs_module_file("file.ext") - int obs_load_module(const char *name); Changed to: int obs_open_module(obs_module_t *module, const char *path, const char *data_path); bool obs_init_module(obs_module_t module); Change the module loading API so that if the front-end chooses, it can load modules directly from a specified path, and associate a data directory with it on the spot. The module will not be initialized immediately; obs_init_module must be called on the module pointer in order to fully initialize the module. This is done so a module can be disabled by the front-end if the it so chooses. New API: - void obs_add_module_path(const char *bin, const char *data); These functions allow you to specify new module search paths to add, and allow you to search through them, or optionally just load all modules from them. If the string %module% is included, it will replace it with the module's name when that string is used as a lookup. Data paths are now directly added to the module's internal storage structure, and when obs_find_module_file is used, it will look up the pointer to the obs_module structure and get its data directory that way. Example: obs_add_module_path("/opt/obs/my-modules/%module%/bin", "/opt/obs/my-modules/%module%/data"); This would cause it to additionally look for the binary of a hypthetical module named "foo" at /opt/obs/my-modules/foo/bin/foo.so (or libfoo.so), and then look for the data in /opt/obs/my-modules/foo/data. This gives the front-end more flexibility for handling third-party plugin modules, or handling all plugin modules in a custom way. - void obs_find_modules(obs_find_module_callback_t callback, void *param); This searches the existing paths for modules and calls the callback function when any are found. Useful for plugin management and custom handling of the paths by the front-end if desired. - void obs_load_all_modules(void); Search through the paths and both loads and initializes all modules automatically without custom handling. - void obs_enum_modules(obs_enum_module_callback_t callback, void *param); Enumerates currently opened modules.
2014-07-27 12:00:11 -07:00
/**
* Returns the location to a module data file associated with the current
* module. Free with bfree when complete. Equivalent to:
libobs: Fix obs-module.h typo Fixes a small typo in the obs-module.h comments. Closes jp9000/obs-studio#557
2016-06-20 13:19:36 -07:00
* obs_find_module_file(obs_current_module(), file);
(API Change) Refactor module handling Changed API: - char *obs_find_plugin_file(const char *sub_path); Changed to: char *obs_module_file(const char *file); Cahnge it so you no longer need to specify a sub-path such as: obs_find_plugin_file("module_name/file.ext") Instead, now automatically handle the module data path so all you need to do is: obs_module_file("file.ext") - int obs_load_module(const char *name); Changed to: int obs_open_module(obs_module_t *module, const char *path, const char *data_path); bool obs_init_module(obs_module_t module); Change the module loading API so that if the front-end chooses, it can load modules directly from a specified path, and associate a data directory with it on the spot. The module will not be initialized immediately; obs_init_module must be called on the module pointer in order to fully initialize the module. This is done so a module can be disabled by the front-end if the it so chooses. New API: - void obs_add_module_path(const char *bin, const char *data); These functions allow you to specify new module search paths to add, and allow you to search through them, or optionally just load all modules from them. If the string %module% is included, it will replace it with the module's name when that string is used as a lookup. Data paths are now directly added to the module's internal storage structure, and when obs_find_module_file is used, it will look up the pointer to the obs_module structure and get its data directory that way. Example: obs_add_module_path("/opt/obs/my-modules/%module%/bin", "/opt/obs/my-modules/%module%/data"); This would cause it to additionally look for the binary of a hypthetical module named "foo" at /opt/obs/my-modules/foo/bin/foo.so (or libfoo.so), and then look for the data in /opt/obs/my-modules/foo/data. This gives the front-end more flexibility for handling third-party plugin modules, or handling all plugin modules in a custom way. - void obs_find_modules(obs_find_module_callback_t callback, void *param); This searches the existing paths for modules and calls the callback function when any are found. Useful for plugin management and custom handling of the paths by the front-end if desired. - void obs_load_all_modules(void); Search through the paths and both loads and initializes all modules automatically without custom handling. - void obs_enum_modules(obs_enum_module_callback_t callback, void *param); Enumerates currently opened modules.
2014-07-27 12:00:11 -07:00
*/
#define obs_module_file(file) obs_find_module_file(obs_current_module(), file)
libobs: Add API func to get module config path Allows the ability to get a module-specific configuration file/path
2015-08-09 05:35:24 -07:00
/**
* Returns the location to a module config file associated with the current
* module. Free with bfree when complete. Will return NULL if configuration
* directory is not set. Equivalent to:
libobs: Fix obs-module.h typo Fixes a small typo in the obs-module.h comments. Closes jp9000/obs-studio#557
2016-06-20 13:19:36 -07:00
* obs_module_get_config_path(obs_current_module(), file);
libobs: Add API func to get module config path Allows the ability to get a module-specific configuration file/path
2015-08-09 05:35:24 -07:00
*/
#define obs_module_config_path(file) \
obs_module_get_config_path(obs_current_module(), file)
Revamp API and start using doxygen The API used to be designed in such a way to where it would expect exports for each individual source/output/encoder/etc. You would export functions for each and it would automatically load those functions based on a specific naming scheme from the module. The idea behind this was that I wanted to limit the usage of structures in the API so only functions could be used. It was an interesting idea in theory, but this idea turned out to be flawed in a number of ways: 1.) Requiring exports to create sources/outputs/encoders/etc meant that you could not create them by any other means, which meant that things like faruton's .net plugin would become difficult. 2.) Export function declarations could not be checked, therefore if you created a function with the wrong parameters and parameter types, the compiler wouldn't know how to check for that. 3.) Required overly complex load functions in libobs just to handle it. It makes much more sense to just have a load function that you call manually. Complexity is the bane of all good programs. 4.) It required that you have functions of specific names, which looked and felt somewhat unsightly. So, to fix these issues, I replaced it with a more commonly used API scheme, seen commonly in places like kernels and typical C libraries with abstraction. You simply create a structure that contains the callback definitions, and you pass it to a function to register that definition (such as obs_register_source), which you call in the obs_module_load of the module. It will also automatically check the structure size and ensure that it only loads the required values if the structure happened to add new values in an API change. The "main" source file for each module must include obs-module.h, and must use OBS_DECLARE_MODULE() within that source file. Also, started writing some doxygen documentation in to the main library headers. Will add more detailed documentation as I go.
2014-02-12 07:04:50 -08:00
/**
* Optional: Declares the author(s) of the module
*
* @param name Author name(s)
*/
clang-format: Apply formatting Code submissions have continually suffered from formatting inconsistencies that constantly have to be addressed. Using clang-format simplifies this by making code formatting more consistent, and allows automation of the code formatting so that maintainers can focus more on the code itself instead of code formatting.
2019-06-22 22:13:45 -07:00
#define OBS_MODULE_AUTHOR(name) \
Revamp API and start using doxygen The API used to be designed in such a way to where it would expect exports for each individual source/output/encoder/etc. You would export functions for each and it would automatically load those functions based on a specific naming scheme from the module. The idea behind this was that I wanted to limit the usage of structures in the API so only functions could be used. It was an interesting idea in theory, but this idea turned out to be flawed in a number of ways: 1.) Requiring exports to create sources/outputs/encoders/etc meant that you could not create them by any other means, which meant that things like faruton's .net plugin would become difficult. 2.) Export function declarations could not be checked, therefore if you created a function with the wrong parameters and parameter types, the compiler wouldn't know how to check for that. 3.) Required overly complex load functions in libobs just to handle it. It makes much more sense to just have a load function that you call manually. Complexity is the bane of all good programs. 4.) It required that you have functions of specific names, which looked and felt somewhat unsightly. So, to fix these issues, I replaced it with a more commonly used API scheme, seen commonly in places like kernels and typical C libraries with abstraction. You simply create a structure that contains the callback definitions, and you pass it to a function to register that definition (such as obs_register_source), which you call in the obs_module_load of the module. It will also automatically check the structure size and ensure that it only loads the required values if the structure happened to add new values in an API change. The "main" source file for each module must include obs-module.h, and must use OBS_DECLARE_MODULE() within that source file. Also, started writing some doxygen documentation in to the main library headers. Will add more detailed documentation as I go.
2014-02-12 07:04:50 -08:00
MODULE_EXPORT const char *obs_module_author(void); \
clang-format: Apply formatting Code submissions have continually suffered from formatting inconsistencies that constantly have to be addressed. Using clang-format simplifies this by making code formatting more consistent, and allows automation of the code formatting so that maintainers can focus more on the code itself instead of code formatting.
2019-06-22 22:13:45 -07:00
const char *obs_module_author(void) { return name; }
Revamp API and start using doxygen The API used to be designed in such a way to where it would expect exports for each individual source/output/encoder/etc. You would export functions for each and it would automatically load those functions based on a specific naming scheme from the module. The idea behind this was that I wanted to limit the usage of structures in the API so only functions could be used. It was an interesting idea in theory, but this idea turned out to be flawed in a number of ways: 1.) Requiring exports to create sources/outputs/encoders/etc meant that you could not create them by any other means, which meant that things like faruton's .net plugin would become difficult. 2.) Export function declarations could not be checked, therefore if you created a function with the wrong parameters and parameter types, the compiler wouldn't know how to check for that. 3.) Required overly complex load functions in libobs just to handle it. It makes much more sense to just have a load function that you call manually. Complexity is the bane of all good programs. 4.) It required that you have functions of specific names, which looked and felt somewhat unsightly. So, to fix these issues, I replaced it with a more commonly used API scheme, seen commonly in places like kernels and typical C libraries with abstraction. You simply create a structure that contains the callback definitions, and you pass it to a function to register that definition (such as obs_register_source), which you call in the obs_module_load of the module. It will also automatically check the structure size and ensure that it only loads the required values if the structure happened to add new values in an API change. The "main" source file for each module must include obs-module.h, and must use OBS_DECLARE_MODULE() within that source file. Also, started writing some doxygen documentation in to the main library headers. Will add more detailed documentation as I go.
2014-02-12 07:04:50 -08:00
(API Change) Refactor module handling Changed API: - char *obs_find_plugin_file(const char *sub_path); Changed to: char *obs_module_file(const char *file); Cahnge it so you no longer need to specify a sub-path such as: obs_find_plugin_file("module_name/file.ext") Instead, now automatically handle the module data path so all you need to do is: obs_module_file("file.ext") - int obs_load_module(const char *name); Changed to: int obs_open_module(obs_module_t *module, const char *path, const char *data_path); bool obs_init_module(obs_module_t module); Change the module loading API so that if the front-end chooses, it can load modules directly from a specified path, and associate a data directory with it on the spot. The module will not be initialized immediately; obs_init_module must be called on the module pointer in order to fully initialize the module. This is done so a module can be disabled by the front-end if the it so chooses. New API: - void obs_add_module_path(const char *bin, const char *data); These functions allow you to specify new module search paths to add, and allow you to search through them, or optionally just load all modules from them. If the string %module% is included, it will replace it with the module's name when that string is used as a lookup. Data paths are now directly added to the module's internal storage structure, and when obs_find_module_file is used, it will look up the pointer to the obs_module structure and get its data directory that way. Example: obs_add_module_path("/opt/obs/my-modules/%module%/bin", "/opt/obs/my-modules/%module%/data"); This would cause it to additionally look for the binary of a hypthetical module named "foo" at /opt/obs/my-modules/foo/bin/foo.so (or libfoo.so), and then look for the data in /opt/obs/my-modules/foo/data. This gives the front-end more flexibility for handling third-party plugin modules, or handling all plugin modules in a custom way. - void obs_find_modules(obs_find_module_callback_t callback, void *param); This searches the existing paths for modules and calls the callback function when any are found. Useful for plugin management and custom handling of the paths by the front-end if desired. - void obs_load_all_modules(void); Search through the paths and both loads and initializes all modules automatically without custom handling. - void obs_enum_modules(obs_enum_module_callback_t callback, void *param); Enumerates currently opened modules.
2014-07-27 12:00:11 -07:00
/** Optional: Returns the full name of the module */
MODULE_EXPORT const char *obs_module_name(void);
Add module callbacks for loading locale data The module callback obs_module_set_locale will be called after loading the module, and any time the locale is manually changed via core API. When this function is called, the module is expected to load new text lookup values for all the text it uses based upon the current locale.
2014-06-25 00:22:54 -07:00
/** Optional: Returns a description of the module */
MODULE_EXPORT const char *obs_module_description(void);