frontend: Add safe_mode getter to obs-frontend-api - #13912
Draft
FiniteSingularity wants to merge 7 commits into
Draft
FiniteSingularity wants to merge 7 commits into
FiniteSingularity wants to merge 7 commits into
Conversation
This provides the counterpart to the existing "target_disable" function, which also allows the functionality to be factored out of existing helper code that might run this implicitly. Co-authored-by: PatTheMav <PatTheMav@users.noreply.github.com>
Core modules are main OBS Studio functionality implemented as runtime modules, but are conceptually considered mandatory and the application is incomplete without them. This change also introduces a configure-time dependency of core modules on "libobs" (already a generation-time dependency) and produces a library target with the names of all core modules available at build system generation. Co-authored-by: PatTheMav <PatTheMav@users.noreply.github.com>
Moves first-party runtime modules into the "core" directory rather than the "obs-plugins" directory to better differentiate them from legacy plugins as well as existing 3rd-party plugins. This change also requires the existing plugin directory to be explicitly added as a possible module search path by application logic, as libobs's internal logic will not add this path anymore and thus third-party plugins would not be discovered anymore. Co-authored-by: PatTheMav <PatTheMav@users.noreply.github.com>
This adds an ENABLE_FLATPAK option which sets an OS_FLATPAK variable for linux builds, and causes any Flatpak-specific build logic to be enabled at configure time. Co-authored-by: PatTheMav <PatTheMav@users.noreply.github.com>
FiniteSingularity
marked this pull request as draft
September 18, 2026 16:20
7 tasks
FiniteSingularity
force-pushed
the
feature/frontend-api-safe-mode
branch
from
September 19, 2026 18:35
884dcc6 to
43501e2
Compare
Adds a separate code path just for loading core modules based on the list of modules created at build system generation. Paths to load core modules from is platform-specific, but not changeable for users and is thus not changeable by a caller. Instead path discovery is implemented for each platform separately, generating the necessary module loading package directly before handing it over to the existing module load callback function. Co-authored-by: PatTheMav <PatTheMav@users.noreply.github.com>
With this change module loading in the application is managed by the plugin manager and allows the application to explicitly load core modules independantly from 3rd party (plugin) modules. The implementation is split into separate files for different platforms to allow for cleaner code handling the different possible locations and path schemes used, including all possible legacy locations and plugin bundle formats. This change introduces new locations and directory formats for plugins: * WINDOWS: Portable plugins need to be placed in a directory called "plugins" adjacent to the "bin" directory of an OBS Studio installation. * WINDOWS: Plugins need to be packaged into their own directory "bundles", with the associated DLL in the root of the bundle and the associated "data" directory next to it. * WINDOWS: The "obs-plugins" directory adjacent to the "bin" directory is deprecated and considered a legacy location for all plugins. * MACOS: No changes in locations or formats. * LINUX: Plugins distributed via system package managers now need to use the "obs-modules/plugins" directory in the system library directory for binaries, and the "obs/obs-modules/plugins" directory in the system data directory for resources. * LINUX: The "obs-plugins" directories in the system library and system data directories are deprecated. * LINUX: Plugins distributed outside of system packages need to use the same directory format as plugins for Windows (see above). * LINUX: A "portable" plugin location like on Windows is not supported. * LINUX: Proper XDG directory locations are scanned for plugins, using XDG_CONFIG_HOME for the legacy plugin format and XDG_DATA_HOME for the new plugin structure. * LINUX: Changes Flatpak plugin loading to use the new plugin structure (while still supporting the legacy structure), and moves Flatpak specific plugin loading to its own source files. * ALL PLATFORMS: A single environment variable "OBS_PLUGINS_PATH" can now be used to provide a highest-priority location from which to load plugins. This directory needs to contain plugin bundles per the new format. The one exception is Flatpak which does not support loading plugins from an env provided location. * ALL PLATFORMS: A custom legacy plugin locations can still be provided via the "OBS_LEGACY_PLUGINS_PATH" and "OBS_LEGACY_PLUGINS_DATA_PATH" environment variables. These are only compatible with plugins using the legacy format and are considered deprecated. The one exception is Flatpak which does not support loading plugins from an env provided location. Co-authored-by: PatTheMav <PatTheMav@users.noreply.github.com>
Adds a new API call to the frontend API to check if OBS was launched in safe mode. This will primarily be used by core modules that need to know if they should disable certain functionality when OBS is launched in safe mode, e.g.- frontend-tools disabling third party scripts, or websockets turning off the websocket server by default in safe mode.
FiniteSingularity
force-pushed
the
feature/frontend-api-safe-mode
branch
from
September 20, 2026 10:29
43501e2 to
0115538
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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
This PR (which stacks on the Plugin Manager 1.5 PR, #13594) adds a new
bool obs_frontend_is_safe_mode()to the obs frontend API. The function returns a boolean indicating if the OBS frontend was launched in safe mode or not.Motivation and Context
Due to some significant architecture changes in how plugins and core modules are loaded in the plugin manager PR, both the
frontend-toolsandwebsocketscore modules can no longer be kept from loading when OBS is launched in safe mode. Since both of these modules can potentially expose OBS to third party code, we need a way to have those modules determine if OBS was launched in safe mode and change how they load accordingly. This PR adds this capability to the frontend API, and 2 future PRs will be submitted that havefrontend-toolsandwebsocketsproperly handle safe-mode, via querying this function.How Has This Been Tested?
This has been tested on Windows and MacOS, by logging the returned boolean from calling
obs_frontend_is_safe_mode()at launch in both normal mode and safe mode. These changes have no affect on other code, as it retrieves a snapshot for a slice of the frontend's internal state.Types of changes
Checklist: