Since the switch of Windows 2022 GitHub actions runner image to version
20240603.1.1 the Visual Studio version was bumped to 17.10.34928.147.
This results in MSVC version 19.40.33811.0 being used at build time.
Combining this with e.g. the MSVC redistributable version 14.34.31938.0
results in segfaults when calling std::mutex::lock.
See also:
https://developercommunity.visualstudio.com/t/Invalid-code-generation-in-release-1940/10678572
A crash could occur if the plugin window was closed and reopened and a
new resource was added to either the Variable, Action queue, Websocket,
or Twitch tab.
No context object was provided to the signal handlers.
The signal provider is intentionally not deleted when the UI is closed.
Because of this, the signal connections were never cleared when the
underlying tab widget was destroyed.
So, in the case of closing and reopening the settings window, the old
connection with the outdated widget pointers would be called again.
Without this timeout the peak volume update, which was received last,
would be used permanently until the next update arrives.
This might only take place when the source produces audio output again.
OBS might very rarely not update _peak quickly enough when very low
intervals are configured on the General tab.
In that case _peak might be set to negative infinity still, which will
result in unexpected behavior, so we use the previously valid peak value
instead.
* The focus action no longer restores maximized windows
* The focus, maximize, minimize, and close actions will be performed on
all handles matching the given window title
This was already possible previously by inverting the logic with a
"not", however, this should it make it more obvious that this type of
check is possible.
