Add setup wizard (and node/device button and associate folder with node button) #134
Comments
|
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. |
|
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
|
|
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 :-) |
|
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. |
|
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:
Further notes:
|
|
I've been enhancing the first-launch message box to use |
Martchus
changed the title
sten0
changed the title
|
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. |
|
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 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.) |
|
The wizard is now accessible without passing the |
|
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 ;)
|
|
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 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.)
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.
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.) |
|
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. |
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.
I've have actually already implemented that now.
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. |
|
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.
|
|
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. |
|
Ping
|
|
Please reopen |
|
It seems the stale bot no longer accepts email replies :( |
|
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. |
|
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). |
|
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?
|
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).
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.
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.
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.
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". |
|
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. |
|
Not stale.
… Message ID: ***@***.***>
|
|
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. |
|
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
<#134 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ACWYOAIIZ74K6PANJAJVV4DX3SAORANCNFSM5VDXYPZQ>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
|
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. |
|
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
<#134 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ACWYOAIOAHPQUGLQPADR7HDYFU6VZAVCNFSM5VDXYPZ2U5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TCOBSGE4DQNJVHAYQ>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
|
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. |
|
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
<#134 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ACWYOAJ7PJZVGCT225DSM4TYPYAMHAVCNFSM5VDXYPZ2U5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TCOJQGMZTGNRUGQ4Q>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
|
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. |
|
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
<#134 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ACWYOAL6BAEMEDQ3WKY5SITYZSIMNAVCNFSM5VDXYPZ2U5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TEMBRGU4DMMZZGUZQ>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
Relevant components
syncthingctl)libsyncthing)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
The text was updated successfully, but these errors were encountered: