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.
With this, the database debug flag can only be activated when using swift
with a development build. Setting the development flag in the json also
didn't worked previously as expected because the corresponding function
to get the flag in application.cpp was called before the setup was loaded.
Added debug log messages in case a worker still exists when the `qApp` is destroyed.
This would mean that a `quitAndWait` is missing or is being skipped somewhere.
* 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)
