In this case the connection from the setup detection is not the correct
one. The connection used to apply the settings should generally be used for
querying the QR-code.
When the launcher has already been setup and the wizard is opened and the
currently running Syncthing instance is selected, then the wizard said the
autostart option had no effect on Syncthing itself. However, that's not
correct when the currently running Syncthing instance has already been
started via the internal launcher. This change adds a special note for this
case which is actually correct.
* 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
* Remove experimental pinning feature again and instead allow using a
normal window
* Pinning made it inconvenient to close the (frameless) window again
* Pinning required hiding/showing the window which didn't look very
nice (and setting flags directly via `QWindow` didn't work as well)
* As normal application/window positioning issues on Wayland are less
problematic (and those aren't going to be fixed any time soon, if at all)
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`.
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.
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.