Anyway we’ve completely derailed the topic from “hey, look, a tray utility” to “are services a good fit for Syncthing?”. Can we move this discussion to another thread?
@camsam thanks for the feedback! Glad it’s working for you.
Strange, it looks just fine for me:
Do you have any special DPI settings?
Nope it’s all default, weird.
What resolution are you using? I don’t have my monitors hooked up at the moment so just using standard laptop resolution: 1366x768
When a new device connects I’ve noticed it gives me notifications for each folder I share that it has “Finished Syncing” when there was nothing to sync. Could it not just inform me that a device has connected?
Hmm, that’s strange. My resolution is 1920 x 1080, DPI settings are all standard.
Your picture looks like Windows chose the 16 x 16 version (instead of the 32 x 32 version) of the icon, but it normally shouldn’t do this as SyncTrazor now has all needed icon sizes . Maybe it is somehow related to some of the “unneeded” icon sizes (like 24 x 24) I incorporated into the .ico file which are then used on smaller resolutions (but this is just a guess). Most guidelines say that Windows Vista and higher need the icon sizes 16 x 16, 32 x 32, 48 x 48 and 256 x 256, but the official guidline for example also recommends 40 x 40 (and some more) for some cases with a higher DPI setting .
Yeah, the trigger for the balloon message isn’t ideal at the moment. It’s based on the folder state as reported by Syncthing - a transition away from the ‘syncing’ state triggers the balloon. However as you’ve noticed this isn’t ideal - we get false positives.
It’s intended to be a “oh, good, I changed file X and now I can be sure that it’s syncted to all my other devices” / “oh look, something changed”, but I’m still trying to find a reliable way to determine this. There’s probably a magic combination of remote/local index changed events + folder syncing state, but I’ve yet to determine it. If you watch
%APPDATA%\SyncTrayzor\SyncTrayzor.log, you’ll see the events come in in realtime.
If the balloon’s annoying you, you can turn it off from the Settings.
Oops sorry, I mis-read you originally - thought you were saying the tray icon looked fuzzy. Were you running 1.0.5 before upgrading to 1.0.6? If so, Windows is probably still caching the old tray icon. In my testing I deleted
%LOCALAPPDATA%\IconCache.db and restarted explorer, but google suggests
ie4uinit.exe -ClearIconCache will clear the icon cache as well.
No I wasn’t. I did clear the icon cache anyhow and it hasn’t changed anything.
Service / start on login discussion moved to
Unfortunately I don’t have a 1366x768 display I can test on. When you do hook your monitors up, would you be able to confirm whether Windows chooses a better icon resolution? That would help us narrow down the issue.
http://superuser.com/q/751361/255941 suggests that pinning the application may cause Windows to use the higher resolution. I’m not suggesting this as a solution, but would you be able to confirm whether this happens in your case as well?
Pinning did use a higher resolution icon and looked fine, I will hook up to monitors after work.
Thanks for trying this. How odd. At least someone else has had this issue - pity there’s no posted solution. I’ll do some more googling.
Do you want notifications that devices have connected/disconnected, or just squish the ‘synced’ notifications when a device has connected/disconnected? I can do both. I’m however not entirely sure that I can tell when a device has connected and has had stuff synced to it…
Just to update you - running at a higher resolution plugged into a monitor (1920x1080) didn’t solve the issue. I’d like to see notifications when a device has connected/disconnected as well as file sync notifications. Possibly including the name/path of the file that has been synced?
How odd. Thanks for the report, I’ll try and figure out what Windows is doing. Pinning it brings up the higher resolution, so it’s there, somewhere.
Device connected/disconnected is fine. I can see when a file has been transferred from remote -> local, but not from local -> remote (I can tell that a file has changed locally, but I can’t distinguish between a file being uploaded to a device and the file being spontaneously changed on the device). I guess ‘Synced XXX from YYY’ would be helpful though?
I’ve opened an issue to track this here:
Yes but I’d like “XXX” to include the path i.e. Share Name\Folder\File.ext
Sure - sorry, I wasn’t clear on that point. “Synced \Folder\Dir\File.txt from FriendlyNameOfDevice”
“On the flip side, running a service as a particular user kind of defeats the point of services, and doesn’t support multi-user computers (only the user the service is running as will be able to use Syncthing).”
Well, I’d have to agree and disagree with this point.
True, running services as specific users is tricky and potentially problematic…BUT it’s something that’s done nearly all the time in the Enterprise -generally speaking, all add-on services (anything that is third party or not shipped with windows) is quite often run with a unique user account, with explicit permissions applied.
Not fun, not easy to manage, but it can be done and it does work.
That said, to properly setup SyncThing as a service would require splitting it into a service and a user interface, with the UI storing config info either in the registry or config files accessible by the user, and the service able to read those locations.
Quite a bit more complex. Not being a dev, I’m not sure how to accomplish this kind of thing. Maybe this could be put on the “down the road a ways” list?
@dback, take a look at
I think we’ve ended up aligned with where you’re coming from.
Wow, nice. Good work. Congrats on writing the first native Windows app for Syncthing. I know this must have been a lot of work, and I know all the developers on this project (whether in C#, C++, or Go have worked very hard, and it shows.
I really like how this particular app is in C# . That really enables alot of the suggestions and dreams for UX/UI happen on Windows. I love C# personally for Windows apps – it makes it really easy to get the native look and feel, and it’s fun to code C# apps.
You could even add the ability for Auto-Update in Visual Studio by adding it as a ‘ClickOnce’ deployment – then perhaps host the ClickOnce on syncthing.net or another server. I think all ClickOnce needs is a web server – and not necessarily IIS – you can actually serve up a ClickOnce deployment from a Linux server running Apache or nginx as long as you set the mimetypes.
if there are any open issues for SyncTrayzor or features that need to be added , let me know, as I think I can do these much faster than learning Go. (meaning I just started learning Go, but I have at least 5years of experience coding in C# for Windows).
I toyed with the idea of making a native Window UI, and not displaying Syncthing’s web interface, but rejected it for 2 reasons:
- It would be a lot of effort for not much gain
- Syncthing’s UI is still evolving, and will continue to improve (there’s a new design proposal floating about on the forums). Continuously being behind, and playing catch-up, to Syncthing’s native UI just presents a worse user experience.
To be honest, I’m not a fan of ClickOnce. Using Inno Setup lets me have quite a lot of flexibility with the installer - I can insert custom screens, do custom logic, write registry keys, move things around, etc. There’s talk of rebranding SyncTrayzor - using Inno Setup lets me do this in a clean way without leaving unused guff all over the user’s filesystem. I’m also not sure how my requirements for separate 32-bit and 64-bit installers, with unmanaged components which aren’t referenced by the C# project, would work with ClickOnce.
Also, using GitHub as a distribution platform has a lot of advantages. It’s trusted by users, and they’re more likely to download something from GitHub’s releases pages than they are from a random website.
If you speak another langauge, then please help out with the translation effort! Details are in the README. If you want to take a snipe at any of the open issues please do! Start a discussion in the issue first, though, so we don’t duplicate work. Otherwise, feature requests and bug reports are always welcome.