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:
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 
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:
syncthing-macos
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.virusman to this 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
Thats awesome, thanks!
Damn github, the autoupdater is now broken because the github pages appcast.xml has moved and outputs HTML instead of a clean HTTP 301 (https://xor-gate.github.io/syncthing-macosx/appcast.xml). Probably there is no way current users can get updated to the new url 
, thats life. It is a build from TeamCity I fetched and seems to work 
I guess you can create another repo with the same name?
Yeah it was just a forward, forked the repo back. Renamed it to the old name and the github pages seems to be live again. Few 
For all the interested the project is now succesfull moved to syncthing organisation and a new release (v0.14.49-1) has happend after all the hard work of all
