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)
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
