Syncthing for macOS

Just have a look at my Syncthing Tray. I think I have already driven it a bit further compared to your application. Currently I’m investigating how to use Syncthing as library instead of starting it as external process (works except for stopping/restarting).

My application could work under macOS as well. It also just lacks someone who can do some adjustments for that platform (shouldn’t be many).

Hi @Martchus, I already had a look some time ago at your application. And prefer to have a native experience on OS X and Qt doesn’t feel like that. Also compiling and distributing Qt application on the Mac is more work/disk space than building native applications. I will have a look at the features you implemented and probably can borrow some ideas.

Thanks for pointing out on your application.

Kind regards, Jerry

Couple ideas for how syncthing-macosx could be improved:

  • native macOS notifications of certain things (e.g. recent changes, folder status changes like Out Of Sync, remotes connecting/disconnecting)

  • add more animations (or detail) to the menu bar icon itself to give more feedback on what Syncthing is doing - e.g. make a “pause” version of the icon when all folders are paused, make an “exclamation mark” version to indicate that there’s something up with a folder that might require attention (e.g. Out Of Sync)

Hi guys,

I’m using Syncthing for Mac/Windows and Linux and never used a additional software which offers a smallish tray icon that tells me anything I maybe should know.

I’m very happy, that I only get messages/notifications when I started the WebGUI in a browser.

So, if not implemented already, I suggest a feature called “quite mode”, where no notifications will inform/annoy/distract/enlighten the user, but let him start/stop/pause the Syncthing service easily. :slight_smile:

Also, the program should respect the “Do Not Disturb” OSX-settings.

My tray application (only available for Windows and Linux) has already implemented that. In fact, you can configure exactly which notifications you would like to get. It also tries to reduce the number of notifications (eg. no disconnect notification after standby).

I assume this happens automatically when one uses the regular OSX APIs?

I totaly agree on notification nags. It could make you crazy when the network is flaky or a lot of files are changed. I prefer not to implement such a feature which can burn down your notification area. The notifications which would be nice which need user intervention:

  • New device wants to add you
  • A new folder is shared

I have created a working prototype to route syncthing events to OS X notification area: Notifications new shared folder and new peered device · Issue #52 · syncthing/syncthing-macos · GitHub

As more people starring and using my wrapper because it is now on the syncthing.net frontpage I wanted to get more insight in the usage of installations and upgrades. So I started to prototype a custom upgrades.xor-gate.org server which redirects to github releases. It is not yet ready for production use, but in the next release I will change the upgrades channel from https://xor-gate.github.io/syncthing-macosx/appcast.xml to the new https://upgrades.xor-gate.org/syncthing-macosx/appcast.xml

Ongoing work on this is located on github: https://github.com/xor-gate/syncthing-macosx/issues/62

Perhaps time to move it under our umbrella and put your upgrade business behind our website? @calmh?

Ditto for Synctrayzor?

I would really appreciate running it under the syncthing umbrella and putting the upgrade infrastructure behind the syncthing website. Or else I have to spinup and maintain it myself. It is not a problem for me but as I have nothing running yet we can still make decisions.

I think you have write access to the org, so you should be able just to move it under the umbrella. As for appcast, it looks just like a static file, how would use infer usage from that?

Usage can be analyzed by the amount of HTTP GET requests on the appcast.xml (e.g per 24h). For the amount of downloads per-release a asset download url can be used to trace the same HTTP GET requests and forward it to github (which in turn forwards to AWS S3).

Here is a quick screenshot of the dashboard I created on my development machine. I also created a influxdata/telegraf github releases download poller which is the graph on the bottom.

For more information on the implementation you could see it in https://github.com/xor-gate/syncthing-macosx/issues/62#issuecomment-408218096

If you’re anyway going to rename, chop off the X in the same maneuver?

Thanks for pointing out, I was also thinking about this one. For me it is fine :+1:

It has happend, only I lost my permissions of project settings now to rename it. Thanks all for the faith in the project. https://github.com/syncthing/syncthing-macosx. Also I would like to get a team for the project just like the android thing. Makes life a little more independent, so I also could still hook up travis CI.

Right! I:

  • Renamed the repo to syncthing-macos
  • Added a public team Contributors/macOS with you in it, and with you as maintainer (you can add/remove members). This team does nothing other than enable highlights such as @syncthing/macos, because org members already have write access to all repos.
  • Invited virusman to this team.
  • Added a non-public team syncthing-macos (Admin) with you in it, and with you as maintainer. This gives admin rights to the repo in question.

Thanks Jakob, I just got notified. Will cleanup all references to “the old name and urls” in the upcomming time. For the upgrade tracking we only need to create a cronjob which generates the appcast.xml and host it next to the meta.json (or somewhere else). With those HTTP server logs we could generate stats of “mothership calls”. And update the application building to actually call the new appcast.xml mothership.

The go script is right here: https://github.com/syncthing/syncthing-macos/pull/63. @virusman gave no review comments yet, so it has now been catching dust in its functional state.

I’ll look into that. In the meantime I’ve set up the make debug and make release-dmg steps on the build server, also collecting the obvious artefacts. It’ll build PRs and report back the build status.

https://build.syncthing.net/project.html?projectId=SyncthingMacOS&tab=projectOverview

1 Like

Thats awesome, thanks!