Packman Build Service PMBS

obs-studio.changes Changed

obs-studio.spec Changed

_service Changed

_servicedata Changed

obs-studio-32.1.1.tar.xz/CONTRIBUTING.rst Deleted

@@ -1,120 +0,0 @@
-Contributing
-============
-
-Quick Links for Contributing
-----------------------------
-
-- Compiling and building OBS Studio:
- https://github.com/obsproject/obs-studio/wiki/Install-Instructions
-
-- Our bug tracker:
- https://github.com/obsproject/obs-studio/issues
-
-- Discord Server: https://obsproject.com/discord
-
-- Development chat: #development on the Discord server (see above)
- 
-- Development forum:
- https://obsproject.com/forum/list/general-development.21/
-
-- Developer/API Documentation:
- https://obsproject.com/docs
-
-- To contribute language translations, do not make pull requests.
- Instead, use crowdin. Read here for more information:
- https://github.com/obsproject/obs-studio/wiki/How-To-Contribute-Translations-For-OBS
-
-- To add a new service to OBS Studio please see the service submission guidelines:
- https://github.com/obsproject/obs-studio/wiki/Service-Submission-Guidelines
-
-General Guidelines
-------------------
-
-- The OBS Project uses English as a common language. Please ensure that any
- submissions have at least machine-translated English descriptions and titles.
-
-- Templates for Pull Requests and Issues must be properly filled out. Failure
- to do so may result in your PR or Issue being closed. The templates request
- the bare minimum amount of information required for us to process them.
-
-- Contributors to the OBS Project are expected to abide by the OBS Project Code of Conduct: https://github.com/obsproject/obs-studio/blob/master/COC.rst
-
-Coding Guidelines
------------------
-
-- OBS Studio uses kernel normal form (linux variant), for more
- information, please read here:
- https://github.com/torvalds/linux/blob/master/Documentation/process/coding-style.rst
-
-- Avoid trailing spaces. To view trailing spaces before making a
- commit, use "git diff" on your changes. If colors are enabled for
- git in the command prompt, it will show you any whitespace issues
- marked with red.
-
-- Tabs for indentation, spaces for alignment. Tabs are treated as 8
- columns wide.
-
-- 120 columns max
-
-- Comments and names of variables/functions/etc. must be in English
-
-- Formatting scripts (macOS/Linux only) are available `here <./build-aux>`__
-
-Commit Guidelines
------------------
-
-- OBS Studio uses the 50/72 standard for commits. 50 characters max
- for the title (excluding module prefix), an empty line, and then a
- full description of the commit, wrapped to 72 columns max. See this
- link for more information: http://chris.beams.io/posts/git-commit/
-
-- Make sure commit titles are always in present tense, and are not
- followed by punctuation.
-
-- Prefix each commit's titles with the module name, followed by a colon
- and a space (unless modifying a file in the base directory). After
- that, the first word should be capitalized.
-
- So for example, if you are modifying the obs-ffmpeg plugin::
-
- obs-ffmpeg: Fix bug with audio output
-
- Or for libobs::
-
- libobs: Fix source not displaying
-
- Note: When modifying cmake modules, just prefix with "cmake".
-
-- If you still need examples, please view the commit history.
-
-- Commit titles and descriptions must be in English
-
-AI/Machine Learning Policy
---------------------------
-
-AI/machine learning systems such as those based on the GPT family (Copilot, 
-ChatGPT, etc.) are prone to generating plausible-sounding, but wrong code that
-makes incorrect assumptions about OBS internals or APIs it interfaces with.
-
-This means code generated by such systems will require human review and is 
-likely to require human intervention. If the submitter is unable to undertake
-that work themselves due to a lack of understanding of the OBS codebase and/or
-programming, the submission has a high likelihood of being invalid.
-Such invalid submissions end up taking maintainers' time to review and respond
-away from legitimate submissions.
-
-Additionally, such systems have been demonstrated to reproduce code contained
-in the training data, which may have been originally published under a license
-that would prohibit its inclusion in OBS.
-
-Because of the above concerns, we have opted to take the following policy
-towards submissions with regard to the use of these AI tools:
-
-- Submissions created largely or entirely by AI systems are not allowed.
-
-- The use of GitHub Copilot and other assistive AI technologies is heavily
- discouraged.
-
-- Low-effort or incorrect submissions that are determined to have been
- generated by, or created with aid of such systems may lead to a ban from
- contributing to the repository or project as a whole.

obs-studio-32.1.1.tar.xz/.gitignore -> obs-studio-32.1.2.tar.xz/.gitignore Changed

obs-studio-32.1.2.tar.xz/CODESTYLE.md Added

@@ -0,0 +1,425 @@
+OBS Studio Code Style Guidelines
+================================
+
+The project requires all contributions to have their source code formatted using appropriate formatting tools to reduce the potential impact of stylistic changes to a structured “diff” view of code.
+
+In addition to those automatically enforceable stylistic choices the project also prefers contributions to follow a set of architectural guidelines that are chosen to reduce undefined or unexpected behavior and make code easier to reason about during reviews or maintenance.
+
+## Reducing Potential For Errors
+
+The following guidelines have been established as good practices to reduce some common potential for errors or naive coding practices that have lead to such errors in the past:
+
+* **Always Initialize Variables** - Depending on the programming language, language standard, compiler, and platform, rules for when and how variables are initialized automatically might differ. Thus some variables might have random values at program start and naive code might interpret any value but “0” to mean “correctly initialized” and run into unexpected behavior.
+ * Do not declare or initialize multiple variables on the same line, do not mix declarations and initializations
+
+```C
+int i, v = 0; // BAD - v is initialized to 0, i is uninitialized
+
+
+int i = 0; // GOOD - i is explicitly declared and initialized
+int v = 0; // GOOD - v is separately declared and initialized
+```
+
+* **Do not use “0” as a valid enumeration value by default** - in many cases an enum requires an explicit choice to be made (only one value of a set of “valid” values can be set) and “not making a choice” should not be considered valid
+
+```C
+enum state { ACTIVE, // BAD - zero-initialized enum potentially
+ INACTIVE, // leads to implicit state changes.
+ DELETED
+};
+
+
+enum state { INVALID, // GOOD - zero-initialized enum produces
+ ACTIVE, // an invalid value by default, avoiding
+ INACTIVE, // an implicit state change.
+ DELETED
+};
+
+
+enum state { ACTIVE = 1, // GOOD, zero-initialization fails because
+ INACTIVE = 2, // it’s not a valid enum value to begin with.
+ DELETED = 3
+};
+```
+
+* **Use natural language for variables and types** - expressive code is easier to reason about for maintainers and reviewers and also reduces the mental burden when returning to the same code after even a short absence, as code “says what it does” and variables “tell what they represent”.
+
+```C
+int c = 1; // BAD: What does “c” represent?
+int count = 2; // BAD: Count of “what”?
+int num_bytes = 3; // GOOD: “Num(ber) of bytes”
+
+
+bool valid; // BAD: Meaning is ambiguous
+bool has_valid_key; // GOOD: Describes state of element in an object
+bool is_valid; // GOOD: Describes state of element itself
+bool did_send_packet; // GOOD: Describes state of transaction.
+
+
+float dur = 1.0; // BAD: Unit of duration unknown
+float duration_ms = 5.0; // GOOD: Unit of duration encoded within name
+
+
+// GOOD: Function signature communicates the unit of the delay explicitly.
+start_transition_with_delay(transition_type *transition, float delay_ms);
+```
+
+* **Use compound types rather than individual variables** - information like the size or dimension of an object, a timescale, a position in space, should be logically encoded in a compound type and only “unwrapped” when consumed
+
+```C
+// GOOD: Function signature communicates the unit of the delay explicitly.
+start_transition_with_delay(transition_type *transition, float delay_ms);
+
+
+// EVEN BETTER: Time values encoded as pieces of a fraction (1/1000th of a
+// second representing a “microsecond”) and explicitly passed to
+// the function.
+typedef struct {
+ int_64_t time_value;
+ int_32_t time_scale;
+} time_unit;
+
+
+start_transition_with_delay(transition_type *transition, time_unit delay);
+
+
+// BAD: Behavior encoded in unrelated booleans, maybe even conflicting
+start_transition(transition_type *transition, bool ignore, bool abort);
+
+
+// GOOD: Function signature requires more meaningful enum rather than bool
+enum transition_abort_mode {
+ TRANSITION_ABORT_INVALID, TRANSITION_ABORT_ALL,
+ TRANSITION_ABORT_NEW, TRANSITION_ABORT_NONE
+};
+
+
+// Signature:
+start_transition(transition_type *transition, enum transition_abort_mode);
+```
+
+* **Do not use unnecessary abbreviations** - if a class implements an "Advanced Output", call it AdvancedOutput, not AdvOutput. The same applies to variables holding an instance of the class. Code is read more often than it is written (and indeed the writing part is just the final outcome of a much longer reasoning process) and optimising for the latter incurs a debt on the former.
+* **Name functions after what they do rather than how they do it** - a function’s signature is effectively its “interface” and should provide a hint about which functionality it provides to the caller. The actual implementation should not be relevant to the caller and exposing this information can actually have a net-negative effect as the caller might try to “out-think” the API.
+* **Prefer pure functions and non-mutable variables** - side-effects are harder to keep track of and can lead to confusing results, particularly when following the prior rule. This also ties into a later rule about avoiding global scope, as global (and shared) variables tend to encourage writing code that surreptitiously changes global shared scope, which makes code harder to test and reason about.
+
+> !NOTE
+> This obviously does not apply to methods where the implementation detail is a technical need of the API user e.g., for factory methods where the user has data in a specific place that it needs to be loaded from, such as `MyData::loadFromUrl(const std::string &url)` or `MyData::loadFromFile(const std::filesystem::path &path)` where the “what” is essentially intertwined with the “how”.
+
+* **Do not use specific integer types outside of binary protocols** - for the vast majority of cases using an “int” is sufficient and using a signed type also prevents unexpected overflow issues where a small negative number becomes a massive positive number. Use sized types (and unsigned types) when interacting with binary protocols, bitfields (e.g. to explicitly remove any special meaning from the most-significant bit). Prefer 64-bit integers over unsigned 32-bit integers for large numbers.
+* **Do not micro-optimize and do not attempt to be overly "clever" with an implementation** - to quote Kernighan:
+
+> Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it?
+
+* **Use profiling tools to identify actual opportunities for optimization** - the code that the compiler generates can potentially work in different ways than the source code might suggest and might not even be executed in the same order. Premature optimizations might also prevent the compiler from applying its own, leading to slower code overall. Also be mindful of profiling tools themselves potentially influencing the runtime behaviour of code.
+* **Attempt to actively break code during testing** - do not rely on “happy paths”. Try to be creative and come up with ways to break the assumptions your code might have made. Do not rely on assumptions that data will never be “wrong” or that some other data will always be “there”. As the ISO C++ FAQ calls it:
+
+> Write code that is guaranteed to work, not code that doesn’t seem to break.
+
+* **Write code that will be reasonably easy to understand even 6, 12, or 24 months later** - while it is easy to reason about the state of a program while working on it, much of that “inside knowledge” might be gone even a few weeks later. Writing code that is obvious in what it does (and also why it does certain things and which pieces of data it requires) will make it easier to get back into the mental model behind the code. **Write code so that any newcomer to the project will have a reasonably easy time understanding what it does and why it does it the way it’s implemented.**
+* **Do not rely on global state or singletons** - both are easily abused as shortcuts to avoid implementing a more expressive and safer design. There are valid use cases for global state (like a global “application” instance implemented as a singleton) but those are the exception and not the rule.
+* **Treat programming as a mental exercise and not just as text manipulation** - existing code in particular will have been designed and built with a set of assumptions and theories in mind, which themselves informed the architectural choices made in its implementation. Some changes might seem “quick and easy” but potentially violate those architectural assumptions and thus could leave the code in a precarious state (and indeed might lead to undefined behaviour when yet other code relies on these assumptions not to be violated).
+
+The last point cannot be overstated because it is a common source of friction in long-lived software projects. **Neither source code nor documentation can be a full representation of the “theory” behind the code** and indeed both can never be more than an incomplete “snapshot” of one possible implementation of this theory.
+
+But without a decent understanding of the theory behind the code (or the architectural concerns that went into the current design) one cannot correctly ascertain which changes will be “in line” with the way current code works and might instead violate important principles of it.
+
+And the more such “naive” code (mainly in the form of hacks and workarounds) is piled on, the more difficult the code becomes to work with, culminating in a code base where even shipping “simple” new features becomes a tough exercise (as the code starts to behave in unpredictable ways due to all the violations of the original “theory”).
+
+> !NOTE
+> This principle becomes more obvious with less abstract examples: An image-editing program will have a set of considerations and constraints that went into its design (code and user interface) and just adding the ability to decode video files will not make the program able to edit video, which is an entirely separate discipline with potentially opposing needs and considerations.
+>
+> And indeed any new feature added to the photo editor now has to potentially contend with the reality that it might be faced with a video file instead, adding even more bits and pieces to unrelated parts of the program to handle a scenario the foundation of the program was conceptually (and explicitly) not built for.
+
+## Language Specific Guidance
+
+OBS Studio currently contains code written in the following languages:
+
+* C
+* C++
+* Objective-C/C++
+* Swift
+* CMake
+
+Continuous integration code is mostly based on Powershell, Zsh or Bash scripts, and Python 3.
+
+While C++ and ObjectiveC/C++ are supersets of the C language, the project prefers to treat them individually with their own rules, conventions, and language standards. Thus rules that apply to “C” do not necessarily apply to these languages and indeed some rules will be replaced for those languages.
+
+### C
+
+For “pure” C code the project follows the Linux Kernel Coding Style (https://github.com/torvalds/linux/blob/master/Documentation/process/coding-style.rst). Parts of the guidelines that relate to Emacs, kernel-level allocators, or macros only available in the Linux kernel source code do not apply.
+
+> !IMPORTANT
+> The current C language standard of the project is **C17 without GNU extensions**.
+
+Some additional notes:
+
+* Formatting is checked and can be applied by `clang-format`. The formatting generated by it supersedes any rules in the guidelines.
+* The project uses a line length of 120 characters, and uses tabs for indentation with a tab width of 8 characters.
+
+### C++
+
+The project treats C++ as its own language and not just as “C with classes”. The associated code style guidelines are based on the Google C++ Code Style Guide (https://google.github.io/styleguide/cppguide.html) with changes to some aspects, as listed below.
+
+> !IMPORTANT
+> The current C++ language standard of the project is **C++17 without GNU extensions**. A move to C++20 is currently being considered.
+
+Additions and changes (in the order the associated topics appear in the Google document):
+
+* **Header Files**
+ * OBS Studio uses the “cpp” suffix for C++ source code files rather than “cc” and “hpp” for C++-specific header files
+ * Header guards are permitted, but not required - a simple `#pragma once` is sufficient
+ * Use of forward declarations is permitted for class or struct types, but be mindful of the caveats mentioned in the Style Guide. **Avoid “Structuring code to enable forward declarations”.**
+ * OBS Studio uses a different header include order, documented in a separate section below
+* **Classes**
+ * If any constructor or assignment operator is defined, all 5 types need to be either defined, defaulted, or deleted, including the destructor (**“Rule of Five”**)
+ * Ensure that move constructor and move assignment operator are marked “noexcept” (and implemented accordingly) to avoid possible pessimization when using user-defined types with standard library containers like `std::vector`.
+ * Use multiple-inheritance only for the interface/protocol pattern ("implements an interface as defined by" relationship), avoid the diamond pattern and virtual base classes.
+* **Google-Specific Magic**
+ * OBS Studio does not use `cpplint`
+* **Other C++ Features**
+ * Exceptions can (but don't have to) be used, particularly when no good "sentinel value" can be provided and also to avoid littering the code with correctness checks after every function call. It is preferred to keep the “scope” of exceptions within the same module (i.e., the same executable or library).
+ * Be aware that in C++ any function that is not a destructor and is not explicitly marked as noexcept can potentially throw an exception as part of normal error handling rather than signaling an actual critical failure.
+ * Instance methods that modify any data, even if it is not their own instance's data, should not be marked `const` to signal that they logically mutate some state.
+ * Do not use comments to declare the types in structured bindings
+ * Any guidelines of C++20 features will be evaluated once the project switches to that language standard.
+ * The project does not allow the use of the Boost library.
+ * However the project does allow the use of the “Disallowed standard library features” and some “Nonstandard Extensions”.
+* **Naming**
+ * Use the class name (following type name rules) for the file name of its interface header and implementation file.
+ * Use `camelCase` for instance methods, functions, as well as variables. This also aligns with Qt’s code style.
+ * Existing constants in code are permitted to be kept with `UPPERCASE` names, but new constants should follow the new convention of `kCamelCase`.
+ * Namespaces need to follow type name rules, though the project only uses the “`OBS`” namespace for refactoring of application code for the time being.
+ * Do not use underscore prefixes for any names, as these are reserved for the standard library implementation. Use a trailing underscore for private member variables.
+* **Comments**
+ * Only C++ comment style is permitted for C++ source code, mixing of different styles is not allowed.
+ * Do not use function argument comments.
+* **Formatting**
+ * Formatting is checked and can be applied by `clang-format`. The formatting generated by it supersedes any rules in the guidelines.
+ * The project uses a line length of 120 characters, and uses tabs for indentation with a tab width of 8 characters.
+ * All new C++ code needs to use curly braces for all looping or branching statements. No exceptions.

obs-studio-32.1.2.tar.xz/CONTRIBUTING.md Added

@@ -0,0 +1,123 @@
+OBS Studio Contribution Guidelines
+============
+
+OBS Studio accepts contributions via public **pull requests**, which encompass changes made to the project as well as a written description of the changes made and the motivation behind them.
+
+Pull requests can be opened by any user with sufficient contribution permissions on the platform chosen by the project. Likewise, any user with sufficient access permissions is able to read, comment, and suggest changes to a pull request, but the ultimate decision for or against adopting the suggested changes lies with **project members**.
+
+OBS Studio has shown steady growth of popularity, complexity, and scope throughout its existence. Contributions that demonstrate they have taken the aspects outlined in this document into account (including the impact to the maintainability of the project) will potentially, but not necessarily, have a higher chance of adoption.
+
+> !NOTE
+> Past acceptance of a change, including “prior art” that exists in the codebase, does not guarantee that future, similar, changes will be accepted, as the “state of the art” (code style guidelines, best practices, language standard) is constantly evolving and the project consciously chooses to evolve with them.
+
+These guidelines attempt to provide a set of general rules that any contributor can choose to follow and implement before opening a pull request to reduce review effort and increase its chances for adoption.
+
+## General Contribution Guidelines
+
+The canonical language used by the project is “American English”, which mainly applies to source code and non-translated material. Examples include:
+
+* Commit messages
+* Names of constants, variables, and types
+* Source code comments
+* File names
+
+Appropriate templates are presented to the user when opening a new issue report or pull request on GitHub which are required to be fully filled out to be taken into consideration by the project.
+The template might require checking off items that might not be applicable e.g., the requirement to have the code properly formatted does not apply when the contribution has not changed any source code. **It is permissible and preferred to tick the box regardless**.
+
+Authors of contributions to the OBS Project are expected to abide by the “OBS Project Code of Conduct” available at https://github.com/obsproject/obs-studio/blob/master/COC.rst.
+
+## Commit Authoring Guidelines
+
+The project uses the “50/72” standard for commit messages, which requires that a commit title uses no more than 50 characters, while any consecutive line used for the commit description is allowed to use a maximum of 72 characters (with long lines manually broken up).
+
+The “anatomy” of a correct commit message with description looks like this:
+
+```
+prefix: This is a commit title using 50 characters
+
+This is a commit description line that is allowed to use up to 72 chars
+```
+
+Prefixes are commonly defined by the “module” the commit applies changes to, which has repercussions as to how commit contents are authored (see below).
+
+* Changes made to code for “libobs” should use the “libobs” prefix, similarly changes made to “obs-ffmpeg” use “obs-ffmpeg”.
+* Changes made to multiple modules in the “plugins” directory can use the “plugins” prefix, particularly if the changes are of a similar nature
+* Changes made to files involved in continuous integration (CI) should use the “CI” prefix regardless of the directory name.
+* Changes made to files used by the CMake build system should use the “cmake” prefix”
+
+When in doubt about what the correct prefix for a change might be, the existing commit history might be of help, however project guidelines might have changed in the interim and thus a “past” commit message might not be acceptable for new contributions.
+
+### Commit Messages
+
+The commit message is the primary place for documentation of changes, not only as a summary of “what” was changed, but even more importantly “why” the changes were made and “why” specifically in the way they have been made.
+
+As such the commit message should be written in such a way that it could easily pass as the “Description” and “Motivation and Context” required when opening a new pull request (and indeed platforms like GitHub will automatically copy the commit message into the opening post for a pull request with a single commit).
+
+This ensures that documentation and context are encoded within the source tree and do not require external documents or platforms to ensure this information is not lost.
+
+Many of these ideas match the ideas outlined in https://chris.beams.io/git-commit.
+
+### Commit Content Authoring Guidelines
+
+#### Code Style
+
+All code contributions to the project need to follow code style guidelines appropriate to the languages used by the changed files. For C and C++ the project has chosen to adopt well-established code style guidelines as its baseline with specific exceptions and changes outlined in a separate document(https://github.com/obsproject/obs-studio/blob/master/CODESTYLE.md).
+
+The baseline rules for the common languages used by the project are:
+
+* C code needs to follow the Linux Kernel Coding Style (https://github.com/torvalds/linux/blob/master/Documentation/process/coding-style.rst)
+* C++ code needs to follow OBS Studios’ style guide. Familiarity with the Google C++ Style Guide (https://google.github.io/styleguide/cppguide.html) can serve as a baseline.
+* Objective-C and Objective-C++ code needs to follow Apple’s ObjectiveC Conventions (https://developer.apple.com/library/archive/documentation/Cocoa/Conceptual/ProgrammingWithObjectiveC/Conventions/Conventions.html)
+* Swift code needs to follow the API Design Guidelines (https://www.swift.org/documentation/api-design-guidelines/)
+* **The column size limit for all code is 120 characters**
+
+To help with the formatting of code, the project contains configuration files for code-formatters of several languages:
+
+* `clang-format` can be used to correctly format C, C++, Objective-C, and Objective-C++ soure code
+* `swift-format` can be used to correctly format Swift source code
+* `gersemi` can be used to correctly format CMake source code
+
+> !NOTE
+> The “build-aux” directory in the project’s root directory contains scripts that can automate this process and are used by the project’s CI infrastructure to automatically check all contributions that changed corresponding source code files.
+
+#### Commit Contents
+
+The changes contained in a commit should attempt to represent logical “units of change” that make sense in isolation and do not necessarily require any preceding or following commits to work. Indeed if a single commit would potentially leave the project in a broken state (e.g., the project cannot be compiled, the application not run, or basic application functionality cannot function) then it is not a full “unit of change”.
+
+* Changes to misspelled words or purely aesthetic changes should in principle not be individually capable of breaking the project in such a way and are permitted to be grouped into a single “large” commit
+* If a larger change requires some foundation of fixes to the existing code to make sense, those fixes represent a “unit of change” that should be decoupled from the functional changes made on top of them. Even better, such a change should be encapsulated in its own, separate, pull request.
+
+> !IMPORTANT
+> During review and collaboration the need for additional changes can arise quickly. It is permitted (and preferred) to temporarily ignore these guidelines to quickly provide changes required to address review comments and add many small, iterative, commits to the pull request.
+>
+> Once all review comments have been addressed, the changes need to be squashed into existing commits or alternatively a new set of commits can be created from all accumulated changes to restore compliance with the guidelines again.
+
+#### Co-Authorship
+
+Sometimes an open pull request might have been "lost to time" even though its contents might still be a meaningful and positive change. When picking up such a change and authoring a new pull request to "finish it", the original author should be retained as much as possible:
+
+* The original commit can be cherry-picked, which will retain the author information and only change the committer information
+* If the original commit needs to be adjusted and changed as it will not apply to an updated code-base, its original author should be added as a "Co-Author" to the commit message.
+
+```
+libobs: Refactor audio implementation
+
+
+Additional commit description
+<..>
+Co-authored-by: Name <git@address.TLD>
+```
+
+# AI/Machine Learning Policy
+
+AI/machine learning systems such as Copilot, ChatGPT, and Claude, are prone to generating plausible-sounding, but wrong code that makes incorrect assumptions about OBS internals or APIs it interfaces with.
+
+This means code generated by such systems will require human review and is likely to require human intervention. If the submitter is unable to undertake that work themselves due to a lack of understanding of the OBS codebase and/or programming, the submission has a high likelihood of being invalid. Such invalid submissions end up taking maintainers' time to review and respond away from legitimate submissions.
+
+Additionally, such systems have been demonstrated to reproduce code contained in the training data, which may have been originally published under a license that would prohibit its inclusion in OBS.
+
+Because of the above concerns, we have opted to take the following policy towards submissions with regard to the use of these AI tools:
+
+* Submissions created largely or entirely by AI systems are not allowed.
+* The use of GitHub Copilot and other assistive AI technologies is heavily discouraged.
+* Low-effort or incorrect submissions that are determined to have been generated by, or created with aid of such systems may lead to a ban from contributing to the repository or project as a whole.

obs-studio-32.1.1.tar.xz/README.rst -> obs-studio-32.1.2.tar.xz/README.rst Changed

obs-studio-32.1.1.tar.xz/frontend/components/VolumeControl.cpp -> obs-studio-32.1.2.tar.xz/frontend/components/VolumeControl.cpp Changed

@@ -165,6 +165,36 @@
 	}
 }
 
+const QIcon &VolumeControl::getUnassignedIcon()
+{
+	static const QIcon &icon = *new QIcon(":/res/images/unassigned.svg");
+	return icon;
+}
+
+const QIcon &VolumeControl::getMutedIcon()
+{
+	static const QIcon &icon = *new QIcon(":/settings/images/settings/audio.svg");
+	return icon;
+}
+
+const QIcon &VolumeControl::getUnmutedIcon()
+{
+	static const QIcon &icon = *new QIcon(":/settings/images/settings/audio.svg");
+	return icon;
+}
+
+const QIcon &VolumeControl::getMonitorOnIcon()
+{
+	static const QIcon &icon = *new QIcon(":/res/images/headphones.svg");
+	return icon;
+}
+
+const QIcon &VolumeControl::getMonitorOffIcon()
+{
+	static const QIcon &icon = *new QIcon(":/res/images/headphones-off.svg");
+	return icon;
+}
+
 void VolumeControl::obsVolumeChanged(void *data, float)
 {
 	VolumeControl *volControl = static_cast<VolumeControl *>(data);
@@ -600,7 +630,8 @@
 	categoryLabel->setText(labelText);
 	categoryLabel->setAlignment(Qt::AlignCenter);
 
-	utils->polishChildren();
+	style()->polish(categoryLabel);
+	style()->polish(volumeMeter);
 
 	bool forceUpdate = true;
 	volumeMeter->updateBackgroundCache(forceUpdate);
@@ -727,13 +758,6 @@
 	volumeMeter->setMuted((showAsMuted || showAsUnassigned) && !showAsMonitored);
 	setUseDisabledColors(showAsMuted || !isActive);
 
-	// Qt doesn't support overriding the QPushButton icon using pseudo state selectors like :checked
-	// in QSS so we set a checked class selector on the button to be used instead.
-	utils->toggleClass(muteButton, "checked", showAsMuted);
-	utils->toggleClass(monitorButton, "checked", showAsMonitored);
-
-	utils->toggleClass(muteButton, "mute-unassigned", showAsUnassigned);
-
 	muteButton->setChecked(showAsMuted);
 	monitorButton->setChecked(showAsMonitored);
 
@@ -745,36 +769,28 @@
 	monitorButton->setToolTip(monitorTooltip);
 
 	if (showAsUnassigned) {
-		QIcon unassignedIcon;
-		unassignedIcon.addFile(QString::fromUtf8(":/res/images/unassigned.svg"), QSize(16, 16),
-				 QIcon::Mode::Normal, QIcon::State::Off);
-		muteButton->setIcon(unassignedIcon);
+		muteButton->setIcon(getUnassignedIcon());
 	} else if (showAsMuted) {
-		QIcon mutedIcon;
-		mutedIcon.addFile(QString::fromUtf8(":/res/images/mute.svg"), QSize(16, 16), QIcon::Mode::Normal,
-				 QIcon::State::Off);
-		muteButton->setIcon(mutedIcon);
+		muteButton->setIcon(getMutedIcon());
 	} else {
-		QIcon unmutedIcon;
-		unmutedIcon.addFile(QString::fromUtf8(":/settings/images/settings/audio.svg"), QSize(16, 16),
-				 QIcon::Mode::Normal, QIcon::State::Off);
-		muteButton->setIcon(unmutedIcon);
+		muteButton->setIcon(getUnmutedIcon());
 	}
 
 	if (showAsMonitored) {
-		QIcon monitorOnIcon;
-		monitorOnIcon.addFile(QString::fromUtf8(":/res/images/headphones.svg"), QSize(16, 16),
-				 QIcon::Mode::Normal, QIcon::State::Off);
-		monitorButton->setIcon(monitorOnIcon);
+		monitorButton->setIcon(getMonitorOnIcon());
 	} else {
-		QIcon monitorOffIcon;
-		monitorOffIcon.addFile(QString::fromUtf8(":/res/images/headphones-off.svg"), QSize(16, 16),
-				 QIcon::Mode::Normal, QIcon::State::Off);
-		monitorButton->setIcon(monitorOffIcon);
+		monitorButton->setIcon(getMonitorOffIcon());
 	}
 
-	utils->repolish(muteButton);
-	utils->repolish(monitorButton);
+	// Qt doesn't support overriding the QPushButton icon using pseudo state selectors like :checked
+	// in QSS so we set a checked class selector on the button to be used instead.
+	utils->toggleClass(muteButton, "checked", showAsMuted);
+	utils->toggleClass(monitorButton, "checked", showAsMonitored);
+
+	utils->toggleClass(muteButton, "mute-unassigned", showAsUnassigned);
+
+	style()->polish(muteButton);
+	style()->polish(monitorButton);
 
 	updateCategoryLabel();
 }

obs-studio-32.1.1.tar.xz/frontend/components/VolumeControl.hpp -> obs-studio-32.1.2.tar.xz/frontend/components/VolumeControl.hpp Changed

obs-studio-32.1.1.tar.xz/frontend/data/themes/System.obt -> obs-studio-32.1.2.tar.xz/frontend/data/themes/System.obt Changed

@@ -84,22 +84,6 @@
     qproperty-icon: url(:res/images/revert.svg);
 }
 
-.indicator-mute {
-    outline: none;
-}
-
-.indicator-mute::indicator:checked {
-    image: url(:/res/images/mute.svg);
-}
-
-.indicator-mute::indicator:indeterminate {
-    image: url(:/res/images/unassigned.svg);
-}
-
-.indicator-mute::indicator:unchecked {
-    image: url(:/settings/images/settings/audio.svg);
-}
-
 .indicator-expand {
     background: transparent;
     outline: none;
@@ -130,13 +114,6 @@
     qproperty-magnitudeColor: rgb(0, 0, 0);
     qproperty-majorTickColor: rgb(0, 0, 0);
     qproperty-minorTickColor: rgb(50, 50, 50);
-    qproperty-meterThickness: 3;
-
-    /* The meter scale numbers normally use your QWidget font, with size    */
-    /* multiplied by meterFontScaling to get a proportionally smaller font. */
-    /* To use a unique font for the numbers, specify font-family and/or     */
-    /* font-size here, and set meterFontScaling to 1.0.                     */
-    qproperty-meterFontScaling: 0.7;
 }

obs-studio-32.1.1.tar.xz/frontend/data/themes/Yami.obt -> obs-studio-32.1.2.tar.xz/frontend/data/themes/Yami.obt Changed

obs-studio-32.1.1.tar.xz/frontend/data/themes/Yami_Acri.ovt -> obs-studio-32.1.2.tar.xz/frontend/data/themes/Yami_Acri.ovt Changed

obs-studio-32.1.1.tar.xz/frontend/data/themes/Yami_Classic.ovt -> obs-studio-32.1.2.tar.xz/frontend/data/themes/Yami_Classic.ovt Changed

@@ -214,52 +214,26 @@
   background: var(--bg_base);
 }
 
-#hMixerScrollArea VolControl {
-    padding: 0px var(--padding_container);
+#hVolumeWidgets VolumeControl {
     margin-bottom: 1px;
 }
 
-#hMixerScrollArea #volMeterFrame {
+#hVolumeWidgets VolumeControl #volMeterFrame {
     margin-top: var(--spacing_large);
 }
 
-#vMixerScrollArea VolControl {
-    padding: 0px var(--padding_xlarge) var(--spacing_large);
+#vVolumeWidgets VolumeControl {
     border-right: 1px solid var(--bg_window);
 }
 
-#vMixerScrollArea QLabel {
+#vVolumeWidgets VolumeControl QLabel {
     font-size: var(--font_small);
 }
 
-#vMixerScrollArea #volLabel {
+#vVolumeWidgets VolumeControl #volLabel {
     font-size: var(--font_base);
 }
 
-.indicator-mute::indicator,
-.indicator-mute::indicator:unchecked {
-    background-color: var(--bg_base);
-    border: none;
-    width: var(--icon_base_mixer);
-    height: var(--icon_base_mixer);
-    icon-size: var(--icon_base_mixer);
-}
-
-.indicator-mute::indicator:checked {
-    background-color: var(--bg_base);
-}
-
-.indicator-mute::indicator:checked:hover,
-.indicator-mute::indicator:unchecked:hover {
-    background-color: var(--bg_base);
-}
-
-.indicator-mute::indicator:hover,
-.indicator-mute::indicator:unchecked:hover {
-    icon-size: var(--icon_base_mixer);
-    border: none;
-}
-
 #contextContainer {
   background-color: var(--bg_window);
 }
@@ -274,7 +248,6 @@
     qproperty-magnitudeColor: rgb(0,0,0);
     qproperty-majorTickColor: var(--text);
     qproperty-minorTickColor: rgb(122,121,122); /* light */
-    qproperty-meterThickness: 3;
 }
 
 OBSBasicStats {

obs-studio-32.1.1.tar.xz/frontend/data/themes/Yami_Light.ovt -> obs-studio-32.1.2.tar.xz/frontend/data/themes/Yami_Light.ovt Changed

obs-studio-32.1.1.tar.xz/frontend/data/themes/Yami_Rachni.ovt -> obs-studio-32.1.2.tar.xz/frontend/data/themes/Yami_Rachni.ovt Changed

obs-studio-32.1.1.tar.xz/frontend/dialogs/OBSAbout.cpp -> obs-studio-32.1.2.tar.xz/frontend/dialogs/OBSAbout.cpp Changed

obs-studio-32.1.1.tar.xz/frontend/widgets/AudioMixer.cpp -> obs-studio-32.1.2.tar.xz/frontend/widgets/AudioMixer.cpp Changed

@@ -39,7 +39,7 @@
 
 #include "moc_AudioMixer.cpp"
 
-constexpr int GLOBAL_SOURCE_TOTAL = 6;
+constexpr int kGlobalSourceTotal = 6;
 
 namespace {
 bool isHiddenInMixer(obs_source_t *source)
@@ -371,6 +371,7 @@
 	bool show = getMixerVisibilityForControl(control);
 
 	if (show) {
+		control->updateMixerState();
 		control->show();
 	} else {
 		control->hide();
@@ -454,7 +455,7 @@
 {
 	globalSources.clear();
 
-	for (int i = 1; i <= GLOBAL_SOURCE_TOTAL; i++) {
+	for (int i = 1; i <= kGlobalSourceTotal; i++) {
 		OBSSourceAutoRelease source = obs_get_output_source(i);
 		if (source) {
 			auto uuidPointer = obs_source_get_uuid(source);
@@ -708,7 +709,7 @@
 		layout->insertWidget(index, volControl);
 		volControl->setVertical(vertical);
 		volControl->updateName();
-		volControl->updateMixerState();
+		volControl->updateCategoryLabel();
 
 		bool showControl = getMixerVisibilityForControl(volControl);
 
@@ -1015,9 +1016,11 @@
 	uint32_t flags = obs_source_get_output_flags(source);
 
 	if (flags & OBS_SOURCE_AUDIO) {
+		auto mixer = static_cast<AudioMixer *>(data);
 		auto uuidPointer = obs_source_get_uuid(source);
-		QMetaObject::invokeMethod(static_cast<AudioMixer *>(data), "updateControlVisibility",
-					 Qt::QueuedConnection, Q_ARG(QString, QString::fromUtf8(uuidPointer)));
+
+		QMetaObject::invokeMethod(mixer, "updateControlVisibility", Qt::QueuedConnection,
+					 Q_ARG(QString, QString::fromUtf8(uuidPointer)));
 	}
 }
 
@@ -1027,9 +1030,11 @@
 	uint32_t flags = obs_source_get_output_flags(source);
 
 	if (flags & OBS_SOURCE_AUDIO) {
+		auto mixer = static_cast<AudioMixer *>(data);
 		auto uuidPointer = obs_source_get_uuid(source);
-		QMetaObject::invokeMethod(static_cast<AudioMixer *>(data), "updateControlVisibility",
-					 Qt::QueuedConnection, Q_ARG(QString, QString::fromUtf8(uuidPointer)));
+
+		QMetaObject::invokeMethod(mixer, "updateControlVisibility", Qt::QueuedConnection,
+					 Q_ARG(QString, QString::fromUtf8(uuidPointer)));
 	}
 }
 
@@ -1040,8 +1045,10 @@
 	bool audioActive = obs_source_audio_active(source);
 
 	if (flags & OBS_SOURCE_AUDIO && audioActive) {
+		auto mixer = static_cast<AudioMixer *>(data);
 		auto uuidPointer = obs_source_get_uuid(source);
-		QMetaObject::invokeMethod(static_cast<AudioMixer *>(data), "addSource", Qt::QueuedConnection,
+
+		QMetaObject::invokeMethod(mixer, "addSource", Qt::QueuedConnection,
 					 Q_ARG(QString, QString::fromUtf8(uuidPointer)));
 	}
 }
@@ -1052,8 +1059,10 @@
 	uint32_t flags = obs_source_get_output_flags(source);
 
 	if (flags & OBS_SOURCE_AUDIO) {
+		auto mixer = static_cast<AudioMixer *>(data);
 		auto uuidPointer = obs_source_get_uuid(source);
-		QMetaObject::invokeMethod(static_cast<AudioMixer *>(data), "removeSource", Qt::QueuedConnection,
+
+		QMetaObject::invokeMethod(mixer, "updateControlVisibility", Qt::QueuedConnection,
 					 Q_ARG(QString, QString::fromUtf8(uuidPointer)));
 	}
 }
@@ -1065,8 +1074,10 @@
 	bool audioActive = obs_source_audio_active(source);
 
 	if (flags & OBS_SOURCE_AUDIO && audioActive) {
+		auto mixer = static_cast<AudioMixer *>(data);
 		auto uuidPointer = obs_source_get_uuid(source);
-		QMetaObject::invokeMethod(static_cast<AudioMixer *>(data), "addSource", Qt::QueuedConnection,
+
+		QMetaObject::invokeMethod(mixer, "addSource", Qt::QueuedConnection,
 					 Q_ARG(QString, QString::fromUtf8(uuidPointer)));
 	}
 }
@@ -1077,15 +1088,19 @@
 	uint32_t flags = obs_source_get_output_flags(source);
 
 	if (flags & OBS_SOURCE_AUDIO) {
+		auto mixer = static_cast<AudioMixer *>(data);
 		auto uuidPointer = obs_source_get_uuid(source);
-		QMetaObject::invokeMethod(static_cast<AudioMixer *>(data), "removeSource", Qt::QueuedConnection,
+
+		QMetaObject::invokeMethod(mixer, "removeSource", Qt::QueuedConnection,
 					 Q_ARG(QString, QString::fromUtf8(uuidPointer)));
 	}
 }
 
 void AudioMixer::obsSourceRename(void *data, calldata_t *)
 {
-	QMetaObject::invokeMethod(static_cast<AudioMixer *>(data), "queueLayoutUpdate", Qt::QueuedConnection);
+	auto mixer = static_cast<AudioMixer *>(data);
+
+	QMetaObject::invokeMethod(mixer, "queueLayoutUpdate", Qt::QueuedConnection);
 }
 
 void AudioMixer::obsSceneItemVisibleChange(void *data, calldata_t *params)

obs-studio-32.1.1.tar.xz/frontend/widgets/AudioMixer.hpp -> obs-studio-32.1.2.tar.xz/frontend/widgets/AudioMixer.hpp Changed

obs-studio-32.1.1.tar.xz/libobs/obs-config.h -> obs-studio-32.1.2.tar.xz/libobs/obs-config.h Changed

obs-studio-32.1.1.tar.xz/shared/qt/idian/include/Idian/Utils.hpp -> obs-studio-32.1.2.tar.xz/shared/qt/idian/include/Idian/Utils.hpp Changed

Difference Between Revision 4 and Multimedia / obs-studio