The first test really needs to wait until Syncthing is listening. It is not
strictly required for testing the wizard's behavior. However, the next test
for connecting to a running Syncthing instance relies on Syncthing being
ready and listening.
* Show required URL format as placeholder text with an example
* Add explanation where to find API key as placeholder text
* Add explanation to authentication checkbox
* Move API key above authentication as it is more important
* See https://github.com/Martchus/syncthingtray/issues/172
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.