libobs: Deprecate obs_get_transition_by_[name|uuid] #11206
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
obs_get_transition_by_name
is very problematic because transitions are always private and their names aren't unique. This means that the method iterates over all private sources and then takes the first that both is a transition and matches the name we're looking for. However, this could be from anywhere - it could be a frontend transition, but also a source transition, quick transition, or even one from third-party plugins. This is always never what is intended.As such, this method (which should never have been added in the first place) needs to go. In its place,
obs_frontend_get_transitions
returns a list of all frontend transitions (which is usually what people are looking for), and alternativelyobs_get_source_by_uuid
also provides access to private sources.While we're at it,
obs_get_transition_by_uuid
is basically a wrapper forobs_get_source_by_uuid
and not really necessary. UUID's are unique and a source doesn't suddenly change its type, so if you have a transition's UUID you can be pretty sure that when you doobs_get_source_by_uuid
, it will still be a transition.I optimistically set 31.0 as the deprecation version in the docs but will update once that is no longer possible.
Motivation and Context
#11200 revealed that this method did make it in (#5504, c36a5ae). While its usages were quickly removed after the accompanying browser PR got merged (because of the aforementioned problems), the method stayed (I really should have removed it, this is my fault. Or better yet, not even have written it. Three years ago me was a bad programmer (me in three years will probably say the same about current me!)).
How Has This Been Tested?
Checked GitHub code search to find no usages of these methods (besides the usual forks and bindings), which is good.
Checked the PR build of the documentation, looks correct.
Types of changes
Checklist: