The watchdog was used in a few places as a shortcut to skip reading
data. Further, it was used in some places in the UI to display
connectivity. But it also introduced quite some complexity. In some
cases it can be fragile: network accessibilty cannot be looked up on all
platforms/hardware constellations. The connectivity could change
between the last watchdog call and the real call. Hence all readers must
still handle the case where the connection fails.
To simplify swift and further reduce the dependency onto the project
infrastructure (pings etc.), this removes the watchdog.
This also removes the QNetworkConfigurationManager, which is deprecated
and not available with Qt6.
Previous we relyed on the watchdog providing a working shared URL (or
empty URL if no URL was reachable). This creates some overhead and
might not work in all cases because of the time between the call to
getWorkingSharedUrl() and the actual network request. Further, not all
calls that are fetching data from our servers were using the shared URL
from the watchdog anyway.
Lastly, this careful checking if the URL is available is only done for
the shared URL and not for all the other URLs that are queried by swift.
- Mark single argument constructors as explicit
- Remove unused functions
- Avoid default parameters in virtual functions
- Clean up includes
- Do not call static methods through an instance
- And some more...
These methods did not quit the application and hence the application
exits with code -1. Further, when calling swift with a commandline
argument, the user might expect to get a commandline output and not a
GUI popup.
Previously we already switch to loading the bootstrap file only from the
local file (ec42553910).
This removes the remaining parts of loading the bootstrap file from a
remote location.
This also updates the UI in case of parsing errors of the bootstrap.json.
* This was an approach to avoid registration of "local signals"
* that part DID NOT work as planned, as all object's signals are registered
* the refactoring itself nevertheless is NOT a bad idea and has been kept
* as the audio context has this special "concept" and CAfvClient can run on both sides (proxy AND impl.side)
Crashpad handler was initialized quite late since we were waiting for settings. However the settings in crashpad are persistent itself, hence we can start it at the earliest possible time and change the upload settings independently later. The only prerequisite is to have QCoreApplication constructed in order for the application name to be available.
ref T652
When the network is down it can happen the bootstrap file request is not yet timed out but we use our own time out.
In that case we check the cached data upfront by faking a failed web read.
The main reason why CInputManager was singleton is the easy access across
the code. That had the negative side effect that time of destruction was
at a very late stage of the shutdown and could not be controlled by us.
My moving it to CApplication, the access is equally easy (using sApp) and
allows to be cleaned up properly during graceful shutdown.
ref T391
Attempting to manage a worker's lifetime with a smart pointer is a mistake.
It can lead to double-delete or premature-delete bugs, and race conditions.
Workers self-manage their own lifetimes.
