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

155 lines
5.8 KiB
C
Raw Normal View History

Add module UI export capability Add the ability to be able to call and use toolkit-specific or program-specific user interface in modules. User interface code can be either bundled with the module, or 'split' out in to separate libraries (recommended). There are three reasons why splitting is recommended: 1.) It allows plugins to be able to create custom user interface for each toolkit if desired. 2.) Often, UI will be programmed in one language (the language of the toolkit), and core logic may be programmed in another. This allows plugins to keep the languages separated if necessary. 3.) It prevents direct linkage of UI toolkits libraries with core module logic. Splitting is not required, though is recommended if you want your plugin to be more flexible with other user interface toolkits or programs. Will implement a generic properties lookup next, which will be used for automatic UI handling so that plugin UI isn't necessarily required.
2014-01-31 23:49:50 -08: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) 2013-2014 by Hugh Bailey <obs.jim@gmail.com>
Add module UI export capability Add the ability to be able to call and use toolkit-specific or program-specific user interface in modules. User interface code can be either bundled with the module, or 'split' out in to separate libraries (recommended). There are three reasons why splitting is recommended: 1.) It allows plugins to be able to create custom user interface for each toolkit if desired. 2.) Often, UI will be programmed in one language (the language of the toolkit), and core logic may be programmed in another. This allows plugins to keep the languages separated if necessary. 3.) It prevents direct linkage of UI toolkits libraries with core module logic. Splitting is not required, though is recommended if you want your plugin to be more flexible with other user interface toolkits or programs. Will implement a generic properties lookup next, which will be used for automatic UI handling so that plugin UI isn't necessarily required.
2014-01-31 23:49:50 -08: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
the Free Software Foundation, either version 2 of the License, or
(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/>.
******************************************************************************/
#pragma once
Add property list callbacks - Add property list callbacks to sources/outputs/encoders so that if necessary user interface can be automatically generated or perhaps a property list widget can be used for them. - Change some of the property API names. obs_property_list_t felt a bit awkward when actually using it, so I just renamed it to obs_properties_t. - Removed the getdata/setdata nad getparam/setparam functions from sources/services, they will be superseded by the dynamic procedure call API.
2014-02-01 21:46:13 -08:00
#include "util/c99defs.h"
Add module UI export capability Add the ability to be able to call and use toolkit-specific or program-specific user interface in modules. User interface code can be either bundled with the module, or 'split' out in to separate libraries (recommended). There are three reasons why splitting is recommended: 1.) It allows plugins to be able to create custom user interface for each toolkit if desired. 2.) Often, UI will be programmed in one language (the language of the toolkit), and core logic may be programmed in another. This allows plugins to keep the languages separated if necessary. 3.) It prevents direct linkage of UI toolkits libraries with core module logic. Splitting is not required, though is recommended if you want your plugin to be more flexible with other user interface toolkits or programs. Will implement a generic properties lookup next, which will be used for automatic UI handling so that plugin UI isn't necessarily required.
2014-01-31 23:49:50 -08:00
#ifdef __cplusplus
extern "C" {
#endif
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
Add module UI export capability Add the ability to be able to call and use toolkit-specific or program-specific user interface in modules. User interface code can be either bundled with the module, or 'split' out in to separate libraries (recommended). There are three reasons why splitting is recommended: 1.) It allows plugins to be able to create custom user interface for each toolkit if desired. 2.) Often, UI will be programmed in one language (the language of the toolkit), and core logic may be programmed in another. This allows plugins to keep the languages separated if necessary. 3.) It prevents direct linkage of UI toolkits libraries with core module logic. Splitting is not required, though is recommended if you want your plugin to be more flexible with other user interface toolkits or programs. Will implement a generic properties lookup next, which will be used for automatic UI handling so that plugin UI isn't necessarily required.
2014-01-31 23:49:50 -08: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
* Modules can specify custom user-interface-specific exports. UI functions
Add module UI export capability Add the ability to be able to call and use toolkit-specific or program-specific user interface in modules. User interface code can be either bundled with the module, or 'split' out in to separate libraries (recommended). There are three reasons why splitting is recommended: 1.) It allows plugins to be able to create custom user interface for each toolkit if desired. 2.) Often, UI will be programmed in one language (the language of the toolkit), and core logic may be programmed in another. This allows plugins to keep the languages separated if necessary. 3.) It prevents direct linkage of UI toolkits libraries with core module logic. Splitting is not required, though is recommended if you want your plugin to be more flexible with other user interface toolkits or programs. Will implement a generic properties lookup next, which will be used for automatic UI handling so that plugin UI isn't necessarily required.
2014-01-31 23:49:50 -08:00
* can be within the same library as the actual core logic, or separated in to
* different modules to split up UI logic and core module logic.
*
* The reasoning for this is to allow for custom user interface of differing
* toolkits or for automatically generated user interface, or to simply allow
* separation of UI code from core code (which may often be in differing
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
* languages).
Add module UI export capability Add the ability to be able to call and use toolkit-specific or program-specific user interface in modules. User interface code can be either bundled with the module, or 'split' out in to separate libraries (recommended). There are three reasons why splitting is recommended: 1.) It allows plugins to be able to create custom user interface for each toolkit if desired. 2.) Often, UI will be programmed in one language (the language of the toolkit), and core logic may be programmed in another. This allows plugins to keep the languages separated if necessary. 3.) It prevents direct linkage of UI toolkits libraries with core module logic. Splitting is not required, though is recommended if you want your plugin to be more flexible with other user interface toolkits or programs. Will implement a generic properties lookup next, which will be used for automatic UI handling so that plugin UI isn't necessarily required.
2014-01-31 23:49:50 -08: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
/** Modal UI definition structure */
struct obs_modal_ui {
const char *id; /**< Identifier associated with this UI */
const char *task; /**< Task of the UI */
const char *target; /**< UI target (UI toolkit or program name) */
/**
* Callback to execute modal interface.
*
* The @b object variable points to the input/output/encoder/etc. The
* @b ui_data varaible points to the UI parent or UI-specific data to
* be used with the custom user interface.
*
* What @b ui_data points to differs depending on the target, and you
* should use discretion and consistency when using this variable to
* relay information to the UI function. For example, it would be
* ideal to have @b ui_data point to a parent, QWidget for Qt, or a
* wxWindow for wxWidgets, etc., though it's up to the discretion of
* the developer to define that value. Because of the nature of void
* pointers, discretion and consistency is advised.
*
* @param object Pointer/handle to the data associated with this
* call.
* @param ui_data UI data to pass associated with this specific
* target, if any.
* @return @b true if user completed the task, or
* @b false if user cancelled the task.
*/
bool (*exec)(void *object, void *ui_data);
};
Add module UI export capability Add the ability to be able to call and use toolkit-specific or program-specific user interface in modules. User interface code can be either bundled with the module, or 'split' out in to separate libraries (recommended). There are three reasons why splitting is recommended: 1.) It allows plugins to be able to create custom user interface for each toolkit if desired. 2.) Often, UI will be programmed in one language (the language of the toolkit), and core logic may be programmed in another. This allows plugins to keep the languages separated if necessary. 3.) It prevents direct linkage of UI toolkits libraries with core module logic. Splitting is not required, though is recommended if you want your plugin to be more flexible with other user interface toolkits or programs. Will implement a generic properties lookup next, which will be used for automatic UI handling so that plugin UI isn't necessarily required.
2014-01-31 23:49:50 -08: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
* Regsiters a modal UI definition to the current obs context. This should be
* used in obs_module_load.
Add module UI export capability Add the ability to be able to call and use toolkit-specific or program-specific user interface in modules. User interface code can be either bundled with the module, or 'split' out in to separate libraries (recommended). There are three reasons why splitting is recommended: 1.) It allows plugins to be able to create custom user interface for each toolkit if desired. 2.) Often, UI will be programmed in one language (the language of the toolkit), and core logic may be programmed in another. This allows plugins to keep the languages separated if necessary. 3.) It prevents direct linkage of UI toolkits libraries with core module logic. Splitting is not required, though is recommended if you want your plugin to be more flexible with other user interface toolkits or programs. Will implement a generic properties lookup next, which will be used for automatic UI handling so that plugin UI isn't necessarily required.
2014-01-31 23:49:50 -08: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
* @param info Pointer to the modal definition structure
*/
EXPORT void obs_register_modal_ui(const struct obs_modal_ui *info);
/* ------------------------------------------------------------------------- */
/** Modeless UI definition structure */
struct obs_modeless_ui {
const char *id; /**< Identifier associated with this UI */
const char *task; /**< Task of the UI */
const char *target; /**< UI target (UI toolkit or program name) */
/**
* Callback to create modeless interface.
*
* This function is almost identical to the modal exec function,
* except modeless UI calls return immediately, and typically are
* supposed to return a pointer or handle to the specific UI object
* that was created. For example, a Qt object would ideally return a
* pointer to a QWidget. Again, discretion and consistency is advised
* for the return value.
*
* @param object Pointer/handle to the data associated with this
* call.
* @param ui_data UI data to pass associated with this specific
* target, if any.
* @return Pointer/handle to the modeless UI associated with
* the specific target.
*/
void *(*create)(void *object, void *ui_data);
};
/**
* Registers a modeless UI definition to the current obs context. This should
* be used in obs_module_load.
Add module UI export capability Add the ability to be able to call and use toolkit-specific or program-specific user interface in modules. User interface code can be either bundled with the module, or 'split' out in to separate libraries (recommended). There are three reasons why splitting is recommended: 1.) It allows plugins to be able to create custom user interface for each toolkit if desired. 2.) Often, UI will be programmed in one language (the language of the toolkit), and core logic may be programmed in another. This allows plugins to keep the languages separated if necessary. 3.) It prevents direct linkage of UI toolkits libraries with core module logic. Splitting is not required, though is recommended if you want your plugin to be more flexible with other user interface toolkits or programs. Will implement a generic properties lookup next, which will be used for automatic UI handling so that plugin UI isn't necessarily required.
2014-01-31 23:49:50 -08: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
* @param info Pointer to the modal definition structure
Add module UI export capability Add the ability to be able to call and use toolkit-specific or program-specific user interface in modules. User interface code can be either bundled with the module, or 'split' out in to separate libraries (recommended). There are three reasons why splitting is recommended: 1.) It allows plugins to be able to create custom user interface for each toolkit if desired. 2.) Often, UI will be programmed in one language (the language of the toolkit), and core logic may be programmed in another. This allows plugins to keep the languages separated if necessary. 3.) It prevents direct linkage of UI toolkits libraries with core module logic. Splitting is not required, though is recommended if you want your plugin to be more flexible with other user interface toolkits or programs. Will implement a generic properties lookup next, which will be used for automatic UI handling so that plugin UI isn't necessarily required.
2014-01-31 23:49:50 -08: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
EXPORT void obs_register_modeless_ui(const struct obs_modeless_ui *info);
/* ------------------------------------------------------------------------- */
Add module UI export capability Add the ability to be able to call and use toolkit-specific or program-specific user interface in modules. User interface code can be either bundled with the module, or 'split' out in to separate libraries (recommended). There are three reasons why splitting is recommended: 1.) It allows plugins to be able to create custom user interface for each toolkit if desired. 2.) Often, UI will be programmed in one language (the language of the toolkit), and core logic may be programmed in another. This allows plugins to keep the languages separated if necessary. 3.) It prevents direct linkage of UI toolkits libraries with core module logic. Splitting is not required, though is recommended if you want your plugin to be more flexible with other user interface toolkits or programs. Will implement a generic properties lookup next, which will be used for automatic UI handling so that plugin UI isn't necessarily required.
2014-01-31 23:49:50 -08:00
#define OBS_UI_SUCCESS 0
#define OBS_UI_CANCEL -1
#define OBS_UI_NOTFOUND -2
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
/**
* Requests modal UI to be displayed. Returns when user is complete.
*
* @param name Name of the input/output/etc type that UI was requested for
* @param task Task of the user interface (usually "config")
* @param target Desired target (i.e. "qt", "wx", "gtk3", "win32", etc)
* @param data Pointer to the obs input/output/etc
* @param ui_data UI-specific data, usually a parent pointer/handle (if any)
*
* @return OBS_UI_SUCCESS if the UI was successful,
* OBS_UI_CANCEL if the UI was cancelled by the user, or
* OBS_UI_NOTFOUND if the UI callback was not found
*/
EXPORT int obs_exec_ui(const char *id, const char *task, const char *target,
Add module UI export capability Add the ability to be able to call and use toolkit-specific or program-specific user interface in modules. User interface code can be either bundled with the module, or 'split' out in to separate libraries (recommended). There are three reasons why splitting is recommended: 1.) It allows plugins to be able to create custom user interface for each toolkit if desired. 2.) Often, UI will be programmed in one language (the language of the toolkit), and core logic may be programmed in another. This allows plugins to keep the languages separated if necessary. 3.) It prevents direct linkage of UI toolkits libraries with core module logic. Splitting is not required, though is recommended if you want your plugin to be more flexible with other user interface toolkits or programs. Will implement a generic properties lookup next, which will be used for automatic UI handling so that plugin UI isn't necessarily required.
2014-01-31 23:49:50 -08:00
void *data, void *ui_data);
Add support for modeless UI creation I realized that I had intended modeless UI to be usable by plugins, but it had been pointed out to me that modeless really needs to return a pointer/handle to the user interface object that was created.
2014-02-01 11:48:35 -08:00
/**
Simplify/improve UI exporting a bit more Reduce and simplify the UI export interface. Having to export functions with designated names was a bit silly for this case, it makes more sense for inputs/outputs/etc because they have more functions associated with them, but in this case the callback can be retrieved simply through the enumeration exports. Makes it a bit easier and a little less awkward for this situation. Also, changed the exports and names to be a bit more consistent, labelling them both as either "modal" or "modeless", and changed the UI function calls to obs_exec_ui and obs_create_ui to imply modal/modeless functionality a bit more.
2014-02-01 16:43:32 -08:00
* Requests modeless UI to be created. Returns immediately.
Add support for modeless UI creation I realized that I had intended modeless UI to be usable by plugins, but it had been pointed out to me that modeless really needs to return a pointer/handle to the user interface object that was created.
2014-02-01 11:48:35 -08: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
* @param name Name of the input/output/etc type that UI was requested for
* @param task Task of the user interface
* @param target Desired target (i.e. "qt", "wx", "gtk3", "win32", etc)
* @param data Pointer to the obs input/output/etc
* @param ui_data UI-specific data, usually a parent pointer/handle (if any)
Add support for modeless UI creation I realized that I had intended modeless UI to be usable by plugins, but it had been pointed out to me that modeless really needs to return a pointer/handle to the user interface object that was created.
2014-02-01 11:48:35 -08: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
* @return Pointer/handle to the target-specific modeless object, or
* NULL if not found or failed.
Add support for modeless UI creation I realized that I had intended modeless UI to be usable by plugins, but it had been pointed out to me that modeless really needs to return a pointer/handle to the user interface object that was created.
2014-02-01 11:48:35 -08: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
EXPORT void *obs_create_ui(const char *id, const char *task,
Add support for modeless UI creation I realized that I had intended modeless UI to be usable by plugins, but it had been pointed out to me that modeless really needs to return a pointer/handle to the user interface object that was created.
2014-02-01 11:48:35 -08:00
const char *target, void *data, void *ui_data);
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
Add module UI export capability Add the ability to be able to call and use toolkit-specific or program-specific user interface in modules. User interface code can be either bundled with the module, or 'split' out in to separate libraries (recommended). There are three reasons why splitting is recommended: 1.) It allows plugins to be able to create custom user interface for each toolkit if desired. 2.) Often, UI will be programmed in one language (the language of the toolkit), and core logic may be programmed in another. This allows plugins to keep the languages separated if necessary. 3.) It prevents direct linkage of UI toolkits libraries with core module logic. Splitting is not required, though is recommended if you want your plugin to be more flexible with other user interface toolkits or programs. Will implement a generic properties lookup next, which will be used for automatic UI handling so that plugin UI isn't necessarily required.
2014-01-31 23:49:50 -08:00
#ifdef __cplusplus
}
#endif