* Avoid adding compile definition project-wide
* Use `SYNCTHINGWIDGETS_`-prefix for definition as it is done in other
places as well
* Use `set(… CACHE …)` for this non-boolean cache variable
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`.
Before tests ran until a timeout was reached and failed not with a clear
error message stating the root cause. This is now the case and can be
tested by setting `SYNCTHING_PATH` to e.g. false/true or a non-existing
binary.
This may help with the test issue mentioned in
https://github.com/Martchus/syncthingtray/issues/144 although I could
never reproduce the concrete error message myself.
Otherwise it is not really possible to go back to the start page. Besides,
triggering the setup detection again explicitly might make it more obvious
what's going on.
`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