Qt strict mode disables APIs deemed "'suboptimal' or 'dangerous'" [1]
and "clearly undesirable" [2] by Qt that will be removed in the long
term.
Usages of the APIs in OBS have been removed in the previous commits, and
by setting this flag we keep ourselves from using them again.
The versioning works in a way where e.g. a new addition to this in 6.9
would only be disabled if at least 0x060900 is set. By setting 0xFF0000,
we're effectively disabling any APIs that are deemed to be bad in any
future Qt version (up to 255).
While this could lead to OBS not being buildable against bleeding edge
Qt, it also means that it will be noticed early. Should the disabled API
turn out to be too complex to remove, the value can be downgraded to the
last working one then.
[1] qt/qtbase@3a6c8e02b6
[2] qt/qtbase@f9163ae7a8
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.
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.
The CrashHandler class encapsulates all functionality around unsafe
shutdown detection as well as crash log discovery and log upload.
Each (functional) CrashHandler should be initialized with an app launch
UUID, which enables the handler to disambiguate a sentinel file for the
current app launch from those of prior app launches.
The NonCheckableButton class was previously used for situations where a
*checkable* button was meant to not be checkable by the *user*, but only
through code. This was useful mostly as a styling tool (and to confuse
developers like me as to what it actually did).
The disadvantage is that such a button - a button that is actually
checkable (has the checkable attribute) but ignores the user - still
gets recognized by QAccessible as a checkable button, which has
accessibility issues when used like a normal button (see QTBUG-110737).
We can still get the styling effect on *actually* uncheckable buttons by
giving them a class, so this widget should not be necessary.
Enhanced broadcasting requires system information to be gathered
on the client and submitted to the GetClientConfiguration request
in order to obtain a valid response from the server. This commit
adds support for gathering the required information on Linux-based
systems.
The reaction effects that macOS adds by default are confusing to users
as they're turned on by default and users don't know where they come
from or where to turn them off. Setting this flag in the apps Info.plist
prevents them from being turned on by default. The macOS UI makes it
very obvious to the user where they can turn them on should they wish to
do so.
