Hello all. I’ve been working on a tray tool, tentatively called TrayThing, for Syncthing. A very preliminary version is shown below.
I’ve run into a snag in the design of Syncthing that makes developing a controller for it more difficult. It seems like Syncthing forks into two processes when it starts off. Which is fine, but the forked process doesn’t terminate when its parent does, which is a problem. I will try to make it run under a job object so I can terminate the whole tree, but really, it should have a neat way of terminating everything.
I’d really rather not have to implement http inside a simple tray wrapper. I’m not sure a wrapper for syncthing should have to know its GUI API any more than either Linux’s or Windows’ service managers know the APIs for what they control.
At the moment I’m able to successfully terminate things by starting the process suspended and attaching it to a job object before allowing it to run. I can then terminate it by terminating the job. This is the only thing that seemed to work - GenerateConsoleCtrlEvent() wasn’t much help.
Perhaps syncthing could be made to run with a switch that tells it not to use a monitor process at all. That’s really the job ob a service manager script or wrapper tool like mine anyway. The umbrella can itself take on the role of restarting in case of failure.
What is the status of the logo? I’d like to use the logo as the tray icon if possible.
Also, just be aware that there are loads of different tray applications with different levels of complexity on the community contributions docs page.
If you’re doing this for fun, go for it (and add a link to thar docs page), but if you’re doing this because you don’t think that anything else exists, be aware that there are lots of tray tools for Syncthing out there.
Thanks for the heads up. Yes, I’m aware of the others, including your very full featured one. It’s partially for fun, and partially to have a tool that fits my philosophy. Syncthing has a great gui, all I want is a simple tool to start her up and maybe parse the audit data to present file changes to the user.
Would a patch adding a command line switch to Syncthing directing the events stream to stderr be accepted? Something like “syncthing -audit=stderr”? Originally I was going to suggest this because I had been concerned that a polling model wouldn’t be responsive enough for something like a flashing “light” on the tray icon when directories are polled. However I see that doing a get on /rest/events?since=<last#> will block until there is another event, so responsiveness wise it seems like it’ll be ok. That being said, it would really be far simpler, be more responsive still, and use fewer system resources just to do a nice old fashioned select on stderr.
I’ve toyed with just using the audit file itself, which works very well indeed, but then it either grows ad infinitum, or I’m stopping and starting Syncthing just to roll it over.
