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>
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>
When the app is quit on macOS, the underlying process is either
triggered by an application-level "Quit" event or by a main window
"close" event.
If the application-level "Quit" event is the trigger, OBSBasic::saveAll
is called twice: First by Qt's session manager (via OBSApp::commitData)
and another time by the main window's close event handled by
OBSBasic::closeWindow.
However if the main window is closed first (and is the first to call
"saveAll") the underlying OAuth data object is destroyed after the data
has been saved. When the second "saveAll" call takes place, it
encounters a "nullptr" for the auth object, which makes "Auth::Save"
effectively remove any OAuth configuration from the settings file
(undoing prior work).
At the other end, if the application quits first, some dock windows
might have been explicitly closed by Qt before the main window is closed
and thus the second call to "saveAll" will overwrite valid browser dock
state data with incomplete data (any dock that has been closed by Qt
before will not be present in that data).
Wrapping the code responsible for saving OAuth and browser dock state
data in a "std::call_once" block should ensure that this data is only
written once and by whoever gets to call "saveAll" first (at which point
state data is still considered "complete").
RemoteTextThread and WhatsNewInfoThread explicitly convert their results
into QString, but many consumers need std::string, converting them
back. Let's just use std::string directly and only convert to QString
where actually needed.
While it is canonical to use the backspace key as an alternative to the
dedicated "delete" key (which is omitted on many smaller-sized Apple
keyboards), the delete key is still available on full-size Apple
keyboards and obviously third-party keyboards.
This change adds the delete key as an alternative to the backspace key
to allow removal of scene items from the scene list in the UI.
With recent changes to the application shutdown logic, events had to
follow a very strict order as certain elements of shutdown code
depend on other elements not being deallocated prematurely.
This turned the (correct) order of events on macOS upside down and
lead to crashes either when the app was quit from within or when
terminated by the OS.
The fix incorporates multiple elements:
* Removal of the custom "Quit" menu item on macOS to use the default
implementation of Qt's platform plugin.
* Soft-revert (via preprocessor conditionals) parts of the updated
shutdown logic to prevent emitting recursive shutdown events.
* Handle main window close event by simply emitting a "quit" event
on the application instance.
* Update POSIX signal handlers to also simply emit a "quit" event.
In combination these changes reduce the number of different code paths
taken during shutdown:
* Closing the app via the menu item, menu item shortcut, or initiated
by AppKit (OS shutdown/reboot, or quit via Dock/Finder) will emit an
AppKit "terminate" event for orderly shutdown.
* Closing the main window or sending an appropriate POSIX signal
triggers the "terminate" event indirectly by emitting the "quit"
event on the application instance.
Either way a "close" event to the main window happens before the
event loop is terminated and the application instance is torn down
(either directly, or indirectly via Qt's "closeAllWindows" function in
response to "terminate"). The order of events thus is always:
0. Terminate event by AppKit (except when closing the main window)
1. Closing of main window
2. Termination of browser docks
3. Deallocation of main window
4. Termination of application
5. Deallocation of application
NOTE: All this only applies to macOS. The shutdown order and procedures
on Windows and Linux are unchanged.
When the main window is closed and with it the application state is torn
down, browser panels need to be explicitly removed before the the CEF
instance used by the application is shut down itself.
For service-based docks this happens as part of the "reset" of the
"auth" pointer (and thus its destructor), for user-created browser
panels this is achieved by the call to "ClearExtraBrowserDocks".
Because the Youtube app dock is a special browser panel that is created
conditionally, but potentially exists globally, it also has to be
closed this way (if it was created).
Otherwise CEF will force-close the underlying browser host instance as
part of its own shutdown and also deallocate the native window used
by the browser. When the QCefWidget then attempts to detach the
native window from the view hierarchy (to avoid this operation from
potentially closing the root window it is anchored to), it will either
attempt to access a CrFatZombie object (and crash) or access deallocated
memory (and also crash).
Improves app shutdown in a few ways, including separating out different
pieces of the OBSBasic close handler into their own functions.
Removes the crash handler sentinel earlier when the main window is closed,
preventing unclean shutdown warnings when a plugin causes issues. While not
ideal, the dialog is not useful when we cannot specify which plugin caused the
problem.
Increases shutdown priority of the main application so that when OBS interrupts
the session ending, CEF is not closed at the same time. This fixes a crash.
Additional safeguards and event handling to try to ensure a smoother shutdown.
The default of 2500 kbps was chosen 10 years ago and times have changed.
Logs and forums posts show that many users of OBS for recording don't
change their bitrate and end up with a 2.5 mbps recording which looks
terrible.
Now that service bitrate enforcement exists, this will be automatically
capped to the maximum bitrate for streaming services, so the only time
this should result in a problem is if the user's upload speed is the
limiting factor, hopefully rarer these days with increasing internet
speeds.
For phase 1 of the plugin manager, the ability to toggle off/on plugins
to be loaded at launch is provided.
This commit adds a new Plugin Manager dialog which can be accessed from
the Tools menu, which shows a list of all installed 3rd party plugins
with a checkbox to toggle them off or on. If a change is made, the user
is prompted to restart OBS. To allow this, the plugin manager uses a
json based config file stored in the OBS config directory. Additionally
for sources in the source tree, a sample UI has been provided that
indicates any sources whose parent module is disabled, by turning its
title red.
Updates include:
* Use of CrashHandler to provide automatic uploads of the most recent
crash log if an unclean shutdown was detected and it has not been
uploaded yet.
* Detection and handling of unclean shutdowns is delegated entirely to
the CrashHandler class
* Use of OBSLogReply has been replaced with the LogUploadDialog, which
asks for confirmation before new uploads of log files (confirmation is
skipped for files with available upload URLs already - only available
for crash logs with this change)
Architectural changes:
* OBSApp is the layer responsible for application launch and shutdown
states, as well as crash logs and application logs
* The actual handling is delegated to purpose-made classes which OBSApp
owns instances of
* OBSBasic in turn refers to OBSApp for all this functionality, and can
subscribe/connect to appropriate events exposed by OBSApp to this
purpose
* Implementation details (like the existence of the CrashHandler class)
are not exposed to OBSBasic or the LogUploadDialog
The amount of changes for normal log file upload have been purposefully
limited. A proper refactoring of the application log file handling will
move this code out of OBSBasic as well.
With the removal of all legacy code paths, obsconfig.h always exists and
the compile definition always gets set. As such, it's no longer
necessary to check for it.
As removing the definition itself could be seen as a breaking change,
this simply moves the definition to pc.in and cmake.in files for now to
preserve the value for plugins that might expect this to be set. We may
remove the definition entirely in a later release.
To emit frontend events early during OBS' initialization, the
disableSaving state variable needs to be "falsy" (as events will not be
emitted otherwise).
The code path taken for generating a new fallback scene collection
has disableSaving decremented to "enable" saving (and thus frontend
events) already, so it's just the code paths for existing collections
that need this workaround.
Emitting the scene changed and preview scene changed events when a
fallback scene collection has been created has side-effects when
OBS Studio is set to studio mode and can lead to potential crashes,
as the studio mode is still in an invalid state at this point.
