Has Electron been considered as a way to create desktop apps for Syncthing? I have a few Electron-based desktop apps on my Mac that work well, including Riot and Webtorrent. I have not developed an app using Electron myself, but since Syncthing’s native interfsce is HTML5, it seems like a natural fit.
That ships the whole Chrome runtime, which makes the binary weight 50+Mb. Plus it adds a ton of dependencies to run which might not be available on servers.
It’s not a bad idea per-se, but I guess there are already wrappers which make the experience better.
I think it’s an excellent idea. Good enough that I Have A Branch™ somewhere with it half done.
1 Like
You need to patent that and add it to urban dictionary with the meaning “stuff that never sees daylight”
5 Likes
Glad to hear it has been considered and even has its own branch of development, even if it never sees daylight 
Nobody needs multiple installs of the chrome/v8 core: electron, vscode, nodejs et al. Cross-platform is a lie if you run just a webbrowser instance to connect somewhere. You can not make use of OS specific desktop primitives (osx, linux, mac) with those big abstractions.
Why should you care about a bloated gui which is not visible for 95% of the time. E.g dropbox users never complain about missing fancy GUIs (except for the central dropbox.com).
1 Like
Well we don’t need much, basically a tray icon and a browser window which we could achieve with this, so it’s worth exploring.
I am not sure how we’d roll this out though, one day suddenly replace 7mb binary with 70mb binary and start opening windows on top of synctrayzor etc? What if we’re running in a headless environment, do we want to ship 70mb there?
Of course not. This would be a separate distribution, probably an installer for Windows and a .dmg for Mac etc. as an alternative to trayzor and so on.
If it’s an alternative, what’s really the point of adding yet another alternative?
Are you asking what’s the point of having a GUI out of the box? Something I download, double click, and it actually shows something useful on my screen?
There is nothing like that for Mac linked from Syncthing.net currently. There is something for Windows and something for Linux, granted. But they are different, and they do not (I think) mostly show the Syncthing GUI - the one we build, using web technologies.
If we think it’s a good idea to have a web based GUI it boggles my mind how there could be no point to actually having it be easily accessible when the app is run.
1 Like
So I am not arguing about having it or not. I question how you’d roll it out to the existing user base, given you can’t quantify who’s using what for UIs. Or are you saying it’s a new thing only, and you have to download a new binary with it’s separate upgrade stream to get that?
I would see it as a new thing yes, being the “Syncthing” we offer on the download site from that point on.
The thing we have today would be demoted to something like the mythical “Syncthing Core” or “Backend” or “DatacenterGeek Edition” (I have so many branding ideas!) way down below the fold on the page. If that’s what you want you can find it. Normal users get to choose one of the platform native offerings or the Syncthing cross platform Electron GUI.
Is it possible for you to share that branch, if you think it is current enough to be helpful? Perhaps this is something I could look into as a way to contribute.
Here: https://github.com/syncthing/syncthing/compare/master...calmh:electron
It’s been a year (apparently) and I don’t really remember the state of it. I think it’s just the scaffolding to start up Syncthing and manage a window. There were some issues around javascript and modules and stuff that it looks like I might have started patching.
Use whatever is useful as verbatim or inspiration.
Excellent, thanks! Somehow the “You are in ‘detached HEAD’ state” git message seems appropriate for me at the moment, as if git is mocking me for thinking I can tackle this problem, heh.
3 Likes
For Mac there is indeed no “native gui” only a tray wrapper with some preference dialogs (xor-gate/syncthing-macosx project). But somebody already did a browser instance wrapper with safari for syncthing-macosx but is not integrated.
The nice thing about syncthing daemon is it can be controlled using an HTTP REST API so everybody is free to build whatever they like or prefer to have for themselves or “customers”. If you language doesn’t have any HTTP and JSON libraries you are doing something wrong.
If you language doesn’t have any HTTP and JSON libraries you are doing something wrong
Ditto ffi…
Not true for Syncthing Tray. The Electron idea is actually the same I have in mind with Syncthing Tray which is not meant to replace the web UI (with something that would look almost the same anyways). Instead, it attempts to add features the web UI can not provide to make the web UI more accessible. It can utilize either WebKit or Blink. For that, it is using Qt WebKit or Qt WebEngine. Both can be shared with other applications requiring it. Under Linux this happens even in practise.
I even implemented some additional details/configurations for the web UI itself:
- zooming (and keep the factor as persistent setting)
- keeping it open in the background (or not)
- when pressing ESC: close an open dialog first and only if none is open the entire window
- all external links are redirected to the default web browser to ensure such pages are not processed by the web view’s engine which might not get security patches so quickly
What’s still missing is calling the native dialog for folder selection, but I have that on my TODO list.
That, combined with the actual tray icon, systemd integration and Dolphin integration, gives a quite good user experience on the Linux desktop in my opinion.
Windows users, on the other side, might not even have been realizing the built-in web view yet because the statically linked Windows binaries do not include it. That’s because like @AudriusButkevicius said it would result in huge binaries.
Because of that I also think depending on an entire web stack (and its dependencies) should be absolutely optional (and I made it even optional in my tray application).
Oh, and Mac users are currently completely excluded because I can not provide support for that platform. However, there are likely only some details to be fixed and it would work there, too.
When reading my answer again, I have to admit it isn’t really clear what I wanted to say.
I wanted to say: There is already an application following the “web UI” approach for providing a (theoretically) cross-platform app. It uses Qt instead of Electron, but the idea is basically the same. It just needs some details fixed to work on Mac as well.
I would also like to add that Qt provides a way to access the “native” web stack as well. Not sure how well that already works but it could prevent deploying a whole web stack.
1 Like