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

[sten0]

Relevant components

• [x] Standalone tray application (based on Qt Widgets)
• [x] 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[bot]]

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 394af9bce7294d99130872133c9facfe8e1d274b). (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 ;)

[Martchus]

Since this is just one feature of Syncthing Tray it makes no sense to consider all of the next releases betas due to the wizard still being experimental. The worst thing that can happen is that it doesn't work and the user has to resort to manual configuration. I don't expect any severe bugs anymore at this point. That's also why I removed it from being guarded behind the --wip flag. Users will surely hit limitations but I guess it is ok.

Showing ones device ID and QR code directly from the wizard is a good idea.

About more advanced configuring of Syncthing itself: That's still not implemented yet as it requires to be able to modify Syncthing's config from within Syncthing Tray. That's something I have not intended to implement from the beginning because it is likely better done within Syncthing's official UI. Maybe I'll look into it nevertheless but if you really want a setup wizard for Syncthing itself it might make sense to ask Syncthing devs directly. (It would likely be fun to implement an Android/mobile UI at some point so then this would also be required. If I'll ever look into making an app I'll definitely try to make the backend code reusable so the wizard can benefit from it as well.)

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.

The wizard is at this point also ready to be used from the plasmoid. It is accessible from the settings. Only showing it on the first launch (or rather "adding" in this case) is missing. Note that WIP features can also be tested using the Plasmoid by setting an environment variable (which is now of course no longer relevant for the wizard). I suppose I should document that at some point.

or something else you don't want to support

This is not really my mindset. Just because I don't support something that doesn't mean it shouldn't be possible at all. In fact I also don't support Debian but this doesn't mean one cannot try using Syncthing Tray there. One just has to be aware that this environment has never been tested by upstream and manage one's own expectations. By the way, for the sake of testing this kind of configurability is actually an important feature and therefore the executable path and service names are actually overridable via an environment variable. (I just didn't bother mentioning this because users are likely not interested in setting environment variables before starting a wizard.)

[stale[bot]]

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]

Since this is just one feature of Syncthing Tray it makes no sense to consider all of the next releases betas due to the wizard still being experimental. The worst thing that can happen is that it doesn't work and the user has to resort to manual configuration. I don't expect any severe bugs anymore at this point. That's also why I removed it from being guarded behind the --wip flag. Users will surely hit limitations but I guess it is ok.

At this point I'd say the feature is stable enough. At least I haven't gotten any bug reports besides problems with running the test suite.

Showing ones device ID and QR code directly from the wizard is a good idea.

I've have actually already implemented that now.

The wizard is at this point also ready to be used from the plasmoid. It is accessible from the settings. Only showing it on the first launch (or rather "adding" in this case) is missing.

Showing the wizard on the first "adding" of the Plasmoid has also been implemented.

---

I guess what's still missing is UI for adding folders and devices. However, for having this within the wizard one needed to have that kind of UI (and required backend functions) first at all.

Supposedly it would also be nice to have a simple way of enabling dark mode on Windows. That kind of setting would also fit well into the wizard.

[sten0]

Martchus @.***> writes:

At this point I'd say the feature is stable enough. At least I haven't gotten any bug reports besides problems with running the test suite.

That's wonderful news.

Showing ones device ID and QR code directly from the wizard is a good idea.

I've have actually already implemented that now.

Cool!

The wizard is at this point also ready to be used from the plasmoid. It is accessible from the settings. Only showing it on the first launch (or rather "adding" in this case) is missing.

Showing the wizard on the first "adding" of the Plasmoid has also been implemented.

Thanks :)

---

I guess what's still missing is UI for adding folders and devices. However, for having this within the wizard one needed to have that kind of UI (and required backend functions) first at all.

https://forum.syncthing.net/t/guidance-on-using-the-api-to-add-and-accept-devices-and-folders/15432

[stale[bot]]

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.

[sten0]

Ping

[sten0]

Please reopen

[sten0]

It seems the stale bot no longer accepts email replies :(

[stale[bot]]

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've recently setup a new device and I must say Syncthing's official web UI really has some nice featured like picking up a device ID from another device in the local network. I'm not sure whether I can (and want) Syncthing Tray to compete with that official UI. It would likely still make more sense to add a wizard for the remaining steps (to add devices and folders) to Syncting's own UI. The wizard of Syncthing Tray could then simply trigger this "official" wizard in the end (as it already suggests opening the official web UI to proceed configuring).

Before trying to implement this in the official UI one should of course reach out to upstream and ask whether a feature like this is actually wanted and whether it makes sense to implement it at this point (or rather wait until some general UI rework has been concluded).

[sten0]

I've recently setup a new device and I must say Syncthing's official web UI really has some nice featured like picking up a device ID from another device in the local network. I'm not sure whether I can (and want) Syncthing Tray to compete with that official UI. It would likely still make more sense to add a wizard for the remaining steps (to add devices and folders) to Syncting's own UI. The wizard of Syncthing Tray could then simply trigger this "official" wizard in the end (as it already suggests opening the official web UI to proceed configuring).

Agreed, it's nice to see features that enhance discoverability :) Have you ever used Syncthing for Android (or Syncthing Fork for Android)? There are two UIs within the app (the Android-native UI and the Web UI of the bundled Syncthing server), and they don't compete with each other; they compliment each other. It's a nice example how the easy_to_use vs powerful_control problem can be solved. On Android, a casual nontechnical user doesn't ever need to interact with the powerful (and confusing) web UI. Please consider the knowledge paradox; this stuff isn't easy for most people!

Before trying to implement this in the official UI one should of course reach out to upstream and ask whether a feature like this is actually wanted and whether it makes sense to implement it at this point (or rather wait until some general UI rework has been concluded).

Yes, real users actually want to be able to set up small Syncthing networks more easily. Or do you mean whether or not upstream is interested in maintaining a quickstart wizard? Would you like me to open the discussion with upstream Syncthing? Concretely, what are your actual concerns?

[Martchus]

It's a nice example how the easy_to_use vs powerful_control problem can be solved.

I know the app as I'm using the fork version myself. It is true that both UIs complement each other. However, I don't think that this helps with the user experience. Having to decide which UI is best for a given task is actually another hurdle. For instance, a casual user might actually benefit from the device discovery feature (as this feature is pretty easy to use) but might not even be aware that it is actually usable on Android as well because it is "hidden" in the web UI. I don't want Syncthing Tray to hide nice features of Syncthing itself like this. (How the current UI of Syncthing Tray is designed makes it hopefully clear that Syncthing Tray is only providing a condensed view.)

Unfortunately the Android app's UI cannot really avoid providing a native UI (to avoid the problem mentioned in the previous paragraph) because supposedly only the native UI can trigger a file dialog (which is quite important on Android for multiple reasons).

Please consider the knowledge paradox; this stuff isn't easy for most people!

I'm not saying that a wizard is useless. It is in fact useful for less experienced users. I'm just saying that it is better implemented in the official UI so all Syncthing users can benefit from it and to avoid the problems mentioned before.

Or do you mean whether or not upstream is interested in maintaining a quickstart wizard?

I'm just saying that it is likely a bad idea to just do some coding and create a PR. It would be better to coordinate with upstream first. Maybe they have even already done some planing in this regard. I've seen that there is some UI overhaul in the works. Maybe they don't want to add too much anymore to the old/current UI at this point as the current focus lies on the future one.

Would you like me to open the discussion with upstream Syncthing?

If you like to move this forward. I personally haven't moved it forward because I'm busy enough tweaking some other details and can live without this feature. If you create an issue on their repository, please mention this issue here for context and then GitHub should be able to create a back-reference.

Concretely, what are your actual concerns?

It would be very frustrating to spend a lot of time creating a PR and then they say for instance "this is too complex", "this is not what we've envisioned" or "we are focusing on a future UI replacement first".

[stale[bot]]

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.

[sten0]

Not stale.

Message ID: @.***>

[stale[bot]]

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.

[sten0]

Ping

On Thu, 21 Sep 2023, 14:20 stale[bot], @.***> wrote:

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.

— Reply to this email directly, view it on GitHub https://github.com/Martchus/syncthingtray/issues/134#issuecomment-1730082677, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACWYOAIIZ74K6PANJAJVV4DX3SAORANCNFSM5VDXYPZQ . You are receiving this because you authored the thread.Message ID: @.***>

[stale[bot]]

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.

[sten0]

Ping

On Tue, 21 Nov 2023, 19:05 stale[bot], @.***> wrote:

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.

— Reply to this email directly, view it on GitHub https://github.com/Martchus/syncthingtray/issues/134#issuecomment-1821885581, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACWYOAIOAHPQUGLQPADR7HDYFU6VZAVCNFSM5VDXYPZ2U5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TCOBSGE4DQNJVHAYQ . You are receiving this because you authored the thread.Message ID: @.***>

[stale[bot]]

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.

[sten0]

Ping

On Sun, 21 Jan 2024, 23:20 stale[bot], @.***> wrote:

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.

— Reply to this email directly, view it on GitHub https://github.com/Martchus/syncthingtray/issues/134#issuecomment-1903336449, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACWYOAJ7PJZVGCT225DSM4TYPYAMHAVCNFSM5VDXYPZ2U5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TCOJQGMZTGNRUGQ4Q . You are receiving this because you authored the thread.Message ID: @.***>

[stale[bot]]

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.

[sten0]

ping

On Fri, 22 Mar 2024 at 16:32, stale[bot] @.***> wrote:

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.

— Reply to this email directly, view it on GitHub https://github.com/Martchus/syncthingtray/issues/134#issuecomment-2015863953, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACWYOAL6BAEMEDQ3WKY5SITYZSIMNAVCNFSM5VDXYPZ2U5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TEMBRGU4DMMZZGUZQ . You are receiving this because you authored the thread.Message ID: @.***>

[stale[bot]]

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.

[sten0]

Ping the stalebot

On Tue, 21 May 2024, 18:05 stale[bot], @.***> wrote:

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.

— Reply to this email directly, view it on GitHub https://github.com/Martchus/syncthingtray/issues/134#issuecomment-2123515037, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACWYOANQGPSQ56HHZK5RNU3ZDPALNAVCNFSM5VDXYPZ2U5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TEMJSGM2TCNJQGM3Q . You are receiving this because you authored the thread.Message ID: @.***>

[stale[bot]]

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.

[sten0]

Ping

On Sat, 20 Jul 2024, 20:06 stale[bot], @.***> wrote:

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.

— Reply to this email directly, view it on GitHub https://github.com/Martchus/syncthingtray/issues/134#issuecomment-2241342091, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACWYOAL43KEO2XO3KW65IYLZNL3PPAVCNFSM5VDXYPZ2U5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TEMRUGEZTIMRQHEYQ . You are receiving this because you authored the thread.Message ID: @.***>