Maybe overriding `HOME` is not sufficient for faking a different home dir
to be picked up by `QStandardPaths`. So this change makes
`LIB_SYNCTHING_CONNECTOR_SYNCTHING_CONFIG_DIR` a hard override and uses it
in tests to fake a different path independently from the behavior of
`QStandardPaths`.
`isUnitAvailable()` would return false for disabled units (that could be
enabled) so `canEnableOrStart()` must return true even if only
`isDisabled()` returns true.
So suppressing notifications by either the launcher status or service
status can be enabled/disabled together with the re-connect tweaking. This
makes more sense than having it unconditionally enabled and makes the
presence of the feature (and when it is effective) also more visible to
users.
* Don't consider the proccess manually stopped by default; otherwise that's
considered to be the case even though the launcher isn't used at all
* Unset the service being manually stopped only when there's an actual
state transition to running; otherwise we'd immediately unset the flag
after manually stopping the service
When the calling code does not return to the event loop (like the CLI test)
we need to run the event loop internally to make sure `bufferOutput()` is
called as of ecd730fd49.
At least when using Qt 6 I could reproduce crashes very often when invoking
`syncthing -version` as part of the wizard's setup detection (inside
a `QIODevice::readAll()` call).
I suppose the problem is that the callback `bufferOutput()` is already
invoked on another thread and emitting the next `readyRead()` signal while
Qt is still handling the previous `readData()` call. Continuing reading
from the pipe only after `readData()` returns should fix it. At least it
does not crash anymore with that change in the wizard's setup detection.
* Read properties from unit interface only if it is valid and set a timeout
to prevent the UI from hanging
* Query the unit file state in case the unit itself cannot be queries so
the file state of disabled units with no status is shown correctly
* Reload unit status when starting a disabled unit with no status so the
effect is visible
Before one only gets the generic error "TLS handshake failed". Now one gets
more details error messages plus the problematic certificate. This should
be helpful for debugging.
Martchus
Julianne420
Hannah Rittich