- 03 2月, 2014 3 次提交
-
-
由 jp9000 提交于
Also, removed some unused headers, and moved the constructor/destructor functions to the top
-
由 jp9000 提交于
-
由 jp9000 提交于
- Implemented better C++ classes for handling scenes/sources/items in obs.hpp, allowing them to automatically increment and decrement the references of each, as well as assign them to QVariants. - Because QVariants are now using the C++ classes, remove the pointer QVariant wrapper. - Use the new C++ classes with the QVariant user data of list box items, both for the sake of thread safety and to ensure that the data referenced is not freed until removed. NOTE: still might need some testing. - Implemented a source-remove signal from libobs, and start using that signal instead of the source-destroy signal for signalling item removal.
-
- 02 2月, 2014 4 次提交
-
-
由 jp9000 提交于
- 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.
-
由 jp9000 提交于
Implement a properties definition interface to allow modules to export general properties associated with objects of libobs. The properties definition interface allows the option for automatic settings UI generation (which will make simple plugins easier to develop without the need for user interface), as well as allow real-time property editing of values of things like sources/outputs/etc without having to open property dialogs. More property types can be added in the future as needed as well.
-
由 jp9000 提交于
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.
-
由 jp9000 提交于
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.
-
- 01 2月, 2014 3 次提交
-
-
由 jp9000 提交于
The ui_enum function gets a const struct obs_ui_info **, which basically means it expects static data to be used. I originally had it the other way around, but yea, it's probably not a good idea, so I'm going to revert back to the original code instead, which doesn't rely on the data being static.
-
由 jp9000 提交于
Made it so that enum_ui returns a const pointer to a structure rather than require an actual structure. Changed a few of the descriptions that I missed.
-
由 jp9000 提交于
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.
-
- 31 1月, 2014 8 次提交
- 30 1月, 2014 8 次提交
-
-
由 jp9000 提交于
Scene items previously were removed by calling obs_sceneitem_destroy, but this proved to be a potential race condition where two different threads could try to destroy the same scene item at the same time. Instead of doing that, reference counting is now used on scene items, and an explicit obs_sceneitem_remove function is used instead for item removal, which sets a 'removed' variable to ensure it can only be called exactly one time.
-
-
由 jp9000 提交于
The previous commit used the scene as a parameter to check to see if the scene item was still present within the scene before destroying, but this was actually unnecessary because the fault was because the destroy signal was being triggered *before* the scene's mutex locked, thus causing a race condition. I changed the code so that it signals after the lock instead of before, so the scene parameter should no longer be necessary.
-
由 Palana 提交于
-
由 Palana 提交于
Prevents another deadlock if removing the scene item triggers source cleanup of a source with graphics resources
-
由 Palana 提交于
Prevents a double free in case the scene item was previously removed
-
由 Palana 提交于
Fixes a deadlock when trying to remove a source from the GUI. The scene item signal handlers would mark the source as removed which results in the video thread also trying to run obs_sceneitem_destroy thereby deadlocking the video thread (and the GUI thread)
-
由 Palana 提交于
Fixes behavior with multiple desktop captures in the same scene Also create the dispatch_queue without a name to prevent name collisions
-
- 29 1月, 2014 11 次提交
-
-
由 BtbN 提交于
-
由 BtbN 提交于
Also, move cpack related code into its own module, to clean up the main CMakeLists.txt
-
由 Palana 提交于
-
由 jp9000 提交于
- Add 'set_default' functions to obs-data.*. These functions ensure that a paramter exists and that the parameter is of a specific type. If not, it will create or overwrite the value with the default setting instead. These functions are meant to be explicitly called before using any of the 'get' functions. The reason why it was designed this way is to encourage defaults to be set in a single place/function. For example, ideal usage is to create one function for your data, "set_my_defaults(obs_data_t data)", set all the default values within that function, and then call that function on create/update, that way all defaults are centralized to a single place. - Ensure that data passed to sources/encoders/outputs/etc is always valid, and not a null value. - While I'm remembering, fix a few defaults of the main program config file data.
-
由 jp9000 提交于
Prevent null dereferencing if data is null, instead just make the functions return and ignore the get/set requests.
-
由 Jim 提交于
I rebuilt obs.icns. Now it corresponds to Table 5-1:
-
由 Palana 提交于
-
由 Palana 提交于
Fixes build due to missing objective c functions on some configurations
-
由 Jim 提交于
Include $ORIGIN in portable mode on unix
-
由 BtbN 提交于
-
由 BtbN 提交于
-
- 28 1月, 2014 3 次提交