If I remember correctly, then syncthingctl has a console so you could also use that for testing. It is using the same libraries under the hood so the behavior should be similar to the GUI.
(And btw, the simplest way to install Mintty would be installing MSYS2 which is in my opinion worthwhile anyways as it really makes Windows suck less.)
I’ve found out what the problem was about. In short, it was a user error. I mistakenly was trying to use cert.pem instead of https-cert.pem as the certificate file, hence the connection couldn’t work, obviously. Apologies for wasting your time on this. It’d still be nice if there was some kind of an error displayed on the screen though 
.
Just for the record, I haven’t tried using MSYS2, but I did experiment with both output redirection and also using bash.exe from Git for Windows, yet there was still nothing logged out there.
This is unrelated to Syncthing Tray itself, but I’d just like to mention that right now it seems impossible to extract https-cert.pem from the Syncthing Android app without root. The app’s internal backup doesn’t export it, and the app data is otherwise inaccessible to the user. On top of that, the app disallows ADB backup, so unless I’m missing something obvious, there really seems to be no way to obtain the cert file in this situation.
Definitely. Normally SSL errors should cause an error that is also not just visible in the logs but in form of a GUI notification. Note that errors are also accessible via the right-click menu in case you miss the notification. (The entry to show internal errors is only visible if there are any.) I’ve just tested it on GNU/Linux, also by swapping https-cert.pem with cert.pem and I’ve got an error notification.
Then you actually have some bits of MSYS2 installed because Git for Windows is using it under the hood. However, you have likely not used Mintty and I presume using bash.exe alone won’t help. Not sure why the redirection didn’t work.
Maybe it is worthwhile to add an option to allow any self-signed cert in Syncthing Tray. That would at least be helpful for quickly testing whether the connection works at all.
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.
Sure. But for getting something done, that which exists trumps the thing that doesn’t. 
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.)
Just a short update on possibly interesting developments:
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:
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.
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.
Hi @Martchus I am a windows user and I like to know where does Syncthing Tray stores is configuration?
%appdata%\syncthingtray.ini
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?