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. |
|
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:
***@***.***>
|
|
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 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
<#134 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ACWYOANQGPSQ56HHZK5RNU3ZDPALNAVCNFSM5VDXYPZ2U5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TEMJSGM2TCNJQGM3Q>
.
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 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
<#134 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ACWYOAL43KEO2XO3KW65IYLZNL3PPAVCNFSM5VDXYPZ2U5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TEMRUGEZTIMRQHEYQ>
.
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: