There’s one bug I could reproduce: If one disables notifications for internal errors then one not only disables the notification but the errors are also no longer accessible from the menu. I’ll fix it when I have time and also add a hint next to the checkbox for internal error notifications where to check for errors then.
This must have been it, because I’ve indeed got all notifications disabled. In the meantime though, I’ve managed to obtain the certificate by opening the Web GUI in a browser first, and then using the browser’s built-in export function to save it as a file. Using the exported certificate, Syncthing Tray has no problems connecting to the GUI.
A feature request for considering conflicts came up. So now I’m wondering whether Syncthing provides an API to query whether a folder has conflicting files (and whether there’s a corresponding event).
I’ve already seen @canton7 's reply in conflict notification via REST API - #7 by canton7 but I don’t know which exact events (from the documentation) these correspond to. It also doesn’t look like LocalChangeDetected/RemoteChangeDetected events would be of help. And besides just relying on events it would also be necessary to know the whether there’s a conflict initially.
Note that I’d personally would like to refrain from messing with the file system on GUI-level. The GUI might run with different permissions than the backend or on a completely different machine so it just wouldn’t make much sense generally.
There is no API for this.
Thanks for the answer. That’s what I’ve expected.
Contributions welcome, of course. I’ve tinkered with the idea of tackling this, but so far haven’t found enough time to pull it through. Too many other items still on the agenda.
Maybe I could give it a shot at some point but as you mentioned in the relevant feature request (that has already been present since January) it won’t be trivial to implement.
There is an API for listing files in a folder (as indexed in the database), though. There’s also one for listing directories on disk, but it only returns directories and not files. It would likely be trivial to extend it for your needs.
Since the conflict files are named after a certain pattern by the Syncthing core, I think implementing a search for such files in the backend would be appropriate though. And of course even more useful, add an event to get notified of newly created conflict files immediately.
1 Like
Sure. But for getting something done, that which exists trumps the thing that doesn’t. 
1 Like
Just for the record, I saw the question. Considering you’ve removed your post I think you’ve already found it out. So I’d just like to note that a setup wizard is currently in the works. This should simplify the setup for common cases in the future. (Not sure whether it’ll be ready for the next release, though.)
1 Like
Just a short update on possibly interesting developments:
- The release 1.2.4 contains the often requested setup wizard as an experimental feature (see Add setup wizard (and node/device button and associate folder with node button) · Issue #134 · Martchus/syncthingtray · GitHub).
- The binaries I provide are now are also based on Qt 6.4.0 which means the dark mode support on Windows should be a little bit better (see updated README section). However, I haven’t tested it myself yet.
- There’s now also a Debian package (see Create and maintain Flatpak and Debian packages · Issue #33 · Martchus/syncthingtray · GitHub). How/whether it can be used on Ubuntu or older Debian versions at this point is not clear yet, though.
1 Like
I was made aware that the last update here has been a while. Well, there’s simply not that much going on. However, a few things are maybe worth highlighting:
- The wizard is no longer considered experimental; it works very well in my opinion. Of course it would still make sense to extend its functionality.
- The dark mode and High DPI support under Windows has improved greatly thanks to changes in Qt 6.5.
- The whole project now generally builds with MSVC. My Windows binaries will still be built with GCC/mingw-w64, though.
- It is now possible to open Syncthing in app-mode using a Chromium-based browser. This is especially useful when using a version of Syncthing Tray that has no built-in web view support enabled (like my Windows binaries).
- Many small problems have been fixed. The next release will also be mainly improve smaller details.
Note that one of the details the next release will improve is the usability when using a console under Windows. This is not very important for Syncthing Tray as it is mainly a GUI application. However, it is quite nice that --help and the exposed CLI of Syncthing itself can now be used properly. The only caveat is that this is only possible via a CLI-wrapper. So one now has to use syncthingtray-cli.exe which will be distributed alongside syncthingtray.exe and internally just invoke the latter. This is basically the same approach as Syncthing itself attempted via Ship "syncthingw" Windows GUI binary (ref #8046, ref #8248) by calmh · Pull Request #8760 · syncthing/syncthing · GitHub - just the opposite way around. I’ve also tried the approach of cmd/syncthing: Compile as GUI application, attach or allocate console instead (ref #8046, ref #8248) by AudriusButkevicius · Pull Request #8763 · syncthing/syncthing · GitHub which I had actually implemented since quite a while. However, I could never really get it to work flawlessly (some of the problems are also mentioned in that issue by @calmh). So I suppose a wrapper is the only way to go.
3 Likes
The last update has again been a while because mostly details have been improved like being able to resize/move the window and what was mentioned in the previous post.
However, now it is maybe worth mentioning that the KDE integrations have been ported to the alpha release of KDE 6. So once KDE 6 is out Syncthing Tray will hopefully be immediately available as well. (Of course you could also test out the alpha of KDE 6 right now. I personally find that it isn’t in too bad shape.) For users of the AUR packaging I have updated the pinned comments accordingly.
I’ve just seen that Qt has introduced a new and more modern style for Windows. It will hopefully address the styling issues the current native Windows style has under Windows 11 and support dark mode (which so far is only possible via the Fusion style). Let’s see when this will be released but I’m looking forward to these visual improvements in a future release of Syncthing Tray.
2 Likes
Hi @Martchus I am a windows user and I like to know where does Syncthing Tray stores is configuration?
1 Like
%appdata%\syncthingtray.ini
2 Likes
Thanks that helped. I am planning on a video about your tool for windows users. I couldn’t find much documentation. Is there a best practice for windows? Like where to store the executable?
The README is the documentation. It currently lacks the file path you’ve been asking for so feel free to extend it. I might going to extend it later myself, though. If you want to contribute to this upstream documentation, please be aware that documentation must be written with all platforms in mind (not just Windows).
You can store the executable wherever you like, just like it is with Syncthing itself. I suppose there’s no best practice. It really depends on your use-case. I actually have it in a directory that is synced by Syncthing itself so Syncthing updates itself on its own after I pull new executables on my server.
My “best practice” in this case is to handle installation through a package management system and let that decide where to store executables. For example on Chocolatey:
1 Like
Good point
