Add setup wizard (and node/device button and associate folder with node button)

[sten0]

Relevant components

• Standalone tray application (based on Qt Widgets)
• Plasmoid/applet for Plasma desktop
• Dolphin integration
• [?] Command line tool (syncthingctl)
• Integrated Syncthing instance (libsyncthing)
• Backend libraries

Is your feature request related to a problem? Please describe.
Everyone I've introduced Syncthing to has found the initial setup really cumbersome. Even career developers.

Describe the solution you'd like
An "Add node (aka Devices)" button, and ability to associate Folders with Devices. A wizard-type interface could be nice too.

Describe alternatives you've considered
As noted, everyone I know has found the web GUI cumbersome and not intuitive at all. This project is already already has the desired functionality:
https://github.com/kozec/syncthing-gtk

[Martchus]

I always refrained from implementing device/folder adding/removing because implementing all options the official web UI has to offer and catching up on changes is a lot of effort that is likely better spent on improving the official web UI itself. Note that Syncthing Tray does not aim to fully replace the web UI (see README) as I think certain features are better implemented in the official GUI instead of every native integration.

If one likes to go ahead and implement that I'd be happy to help. However, the wizard should make it clear that one is possibly missing out configuration options from the regular GUI. The wizard's code should also be shared between the Qt Widgets GUI and the Plasmoid to keep it better maintainable.

Additionally, I'm not even sure what you're asking for exactly. Apparently some kind of wizard that is not even present in the official UI that somehow combines adding devices and folders.

[sten0]

Martchus ***@***.***> writes:

I always refrained from implementing device/folder adding/removing because implementing all options the official web UI has to offer and catching up on changes is a lot of effort that is likely better spent on improving the official web UI itself. Note that Syncthing Tray does not aim to fully replace the web UI (see README) as I think certain features are better implemented in the official GUI instead of every GUI wrapper.

I agree that all options should not be added. That said, the official web UI is very much a powerful administration console. The average desktop user is just confused by all of its buttons, knobs, and settings, and as I noted, even some of my colleagues in Debian are confused by it.

If one likes to go ahead and implement that I'd be happy to help. However, the wizard should make it clear that one is possibly missing out configuration options from the regular GUI. The wizard's code should also be shared between the Qt Widgets GUI and the Plasmoid to keep it better maintainable.

Agreed!

Additionally, I'm not even sure what you're asking for exactly. Apparently some kind of wizard that is not even present in the official UI that somehow combines adding devices and folders.

The wizard would have the following functionality: ``` Check for active Syncthing process if one is not found, then query systemd capabilities if systemd capabilities are found, then systemctl --user enable syncthing.service @optional elseif non-systemd linux system, then the fallback method (I'm not familiar with this) but I think Syncthing Tray already has the ability to manage the Syncthing daemon. # This is optional because all the majority of user-friendly # distributions use systemd, and users not on this distributions # are more likely to be able to manage Syncthing without a wizard @if_relevant elseif Windows, then do something # It's not clear to me if Windows is a target platform query Syncthing for configured folder AND nodes linked to folder # the following should be a function that can be reused by the # user at any time to add additional folders, nodes, and # associations between the two. while if both are not found, then execute folder adding interface execute node adding interface # Let me know if you'd like webcam QR code scanning support # because IIRC there's now finally a library for it! execute folder-to-node linking interface wizard cannot proceed until both are found ``` tldr: The wizard asks "What do you want to Share?" and "Who do you want to share it with?" Making this basic functionality easy allows Syncthing Tray to provide an alternative to Google Drive and Dropbox for the average user. If it's not activated by default, then it's probably also a good idea to expose a UPnP toggle in Syncthing Tray to support make initial setup easier for non-technical users. The security considerations of uPnP must be resolved on the router/firewall and not the desktop/laptop, because any random piece of malware will be able to open a port if this functionality is not disable on the router/firewall. In other words, I don't think it's harmful to enable UPnP in an application. Please let me know if there's anything else I can do to clarify this issue :) Cheers, Nicholas

[Martchus]

Ok, a wizard that guides on on Syncthing Tray's own initial configuration based on some automatic detection of what's already running on the system would certainly make sense. I've already had that idea myself but have never found the time to implement it. That wizzard would replace the current first-launch message then (and could be opened from the settings as well - which would likely also deserve a landing page).

Allowing one to add devices and folders as next step (after Syncthing is running / the connection to Syncthing has been established) would also make sense but of course adding devices/folders needed to be implemented first at all. Tweaking the most important settings of Syncthing itself could of course be done as well. However, it should never go against defaults of Syncthing itself and also never re-configure anything "accidentally" so this feature should be implemented with care.

Maybe I'll find the time/motivation to work on it at some point. I'd go in the order as I've just used to describe the different aspects. Finally a use case for https://doc.qt.io/qt-6/qwizard.html :-)

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[Martchus]

I have actually some time ago thought about how to structure a wizard. Here the past from my notes (maybe I'll take the time to implement that next winter):

---

Wizzard sequence:

0. Welcome page with dismiss option and direct access to normal config
1. Find local config, try to connect
   1.1 If config found and connected, suggest to use config
   1.2 If not connected or connection found via 1.1 is dismissed
   • suggest to enter config manually
   • suggest to launch Syncthing via the internal launcher and configure connecting to that
   • also check for currently running Syncthing processes and warn if one is still running (but could not used via 1.1)
2. Check for systemd units, possibly suggest to configure systemd integration (skip page completely if systemd support is disabled)
3. Show summary/confirmation
4. Allow enabling auto start
5. Allow adding devices/folders

Further notes:

• Re-use widgets from normal settings dialogs as much as possible. Possibly refactor.
• Show wizzard on first startup and allow accessing it from normal config dialog
  • Maybe add "start page" to normal config dialog or "wizzard" button next to filter box which both would be new features
    on qtutilities-level

[Martchus]

I've been enhancing the first-launch message box to use QWizard in preparation for adding a guided/automated setup (see 394af9b). (It can be shown via the hidden parameter --assume-first-launch when Syncthing Tray was launched before.)

[sten0]

Thank you for your work on this, I've noticed it in the commit logs! Re: your notes,

§4 should be part of §1.2, §3 should be the last item.

§2 is the most common mechanism on Linux systems so should be prefered to the internal launcher. The internal launcher should be the fallback on almost all modern systems, because almost all modern systems use systemd. FreeBSD builds will be configured without systemd so the default daemon launch method branch can be determined at configure/compile time.

I appreciate your thoroughness in considering case §1.2.3, which is vanishingly unlikely if a systemctl query succeeds. It seems like the most likely case for this would be a manually configured password (or SSL) via the web GUI.

P.S. Oops, I just spotted my embarassing typo.

[Martchus]

The WIP wizard already allows one to setup Syncthing Tray for the currently running Syncthing instance, for starting Syncthing via systemd (if the unit is installed) and for starting Syncthing via the internal launcher (if it is in path or Syncthing Tray has been configured with the built-in Syncthing library). It also allows one to enable/disable autostart.

It is currently only available in the Qt Widgets based GUI. To test it, start it via --wip which enables experimental features. The wizard is available via a button in the top-right corner of the settings windows (or can be shown via the CLI argument --show-wizard). It will also be shown on the first launch (which can be faked for testing via the CLI argument --assume-first-launch).

So anybody is welcome to help me testing. (You'll still need the mentioned flags in 1.2.4 release as I still consider the wizard experimental.)

[Martchus]

The wizard is now accessible without passing the --wip flag so it'll be available normally in the next release. I have improved it a little bit since I've wrote the last comment. It seems to work when I tested it under Arch Linux and Windows 10. Unfortunately I haven't gotten any feedback from users so there are likely still bugs to be found. Besides that, the wizard currently provides the bare minimum and many things are left to implement (besides missing features like configuration of dark mode or Syncthing itself, it can currently only detect an external Syncthing binary if it is in PATH and the systemd unit file names are also always assumed to be the standard ones).

[sten0]

The wizard is now accessible without passing the --wip flag. I have

improved it a little bit since I've wrote the last comment. It seems to work when I tested it under Arch Linux and Windows 10. Cool :)

Unfortunately I haven't gotten any feedback from users so there are

likely still bugs to be found. Sorry I haven't yet found the time to test. Maybe tag something like a `x.y.z_beta1` release and then wait for the feedback to trickle in? In terms of Debian-related timeline, it will be possible to back-out any experiments up to late December or early January, and a reverted experiment won't propagate to Ubuntu 23.04. The hard deadline for any changes targeting the next Debian (and derivatives) release is the end of January. On Debian, 60% of popcon-participating Syncthing Tray users use the plasmoid, so creating an entry point there seems like it may increase likelihood of feedback. ...but as noted previously I've already gotten feedback: It's too hard to set up a trivial one folder, two or three node mesh. [x] 1. Gets Syncthing running, plus a mechanism to keep it running (systemd or self-managed) [ ] 2. Query Syncthing, list other hosts/nodes if there are any, wizard interface to add a node, and block progress through wizard until a node is added. [ ] 3. Query Syncthing, get list of folders, wizard interface to add a folder, and block if no folders have been added. Typically this will end up being the default folder that Syncthing creates. [ ] 4. Share a folder with a/some node[s], and block if at least one folder has not been shared with one node. To make [2] easier, maybe allow something like calling XDG "mailto" handler to send "device ID" at this step as well as "Display QR code"? From a user perspective it's easier to click "yes" to configuration that is pushed/"introduced" from another node. Maybe waiting for the remote to initiate the connection could be part of [2]? Likewise, [3] would then be initiated by the remote, and when confirmed locally condition [4] would be fulfilled. Different ways to solve the problem :)

Besides that, the wizard currently provides the bare minimum and many

things are left to implement (besides missing features like configuration of dark mode or Syncthing itself, it can currently only detect an external Syncthing binary if it is in PATH and the systemd unit file names are also always assumed to be the standard ones). A GNU/Linux perspective: I think it's good for the wizard's self-managed Syncthing process runner to be limited by PATH, because if the binary isn't in PATH then it's a custom/advanced installation, or a botched installation, or something else you don't want to support...I guess eventually you could add a branch that provides a text-entry box or file-browser/picker interface if you really wanted to support this, but I wouldn't prioritise it. It's also reasonable to assume Syncthing's systemd unit names are a standardised interface...these are also system integration problems that you don't, imho, need to worry about. The packager can patch this stuff to adjust it if necessary ;)