This makes the code more explicit about avoiding triggering the setup
detection twice. Maybe it fixes
https://github.com/Martchus/syncthingtray/issues/174 but likely it does not
change the behavior (in general).
* 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)
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.
The currently running instance might be from the launcher itself as the
wizard might have been started after configuring the launcher manually. So
let's just not mess with the launcher settings at all in this case.
Martchus
Doron Behar