# Yet another Syncthing Tray
**URL:** https://forum.syncthing.net/t/yet-another-syncthing-tray/8502
**Category:** Development
**Created:** [October 30, 2016, 5:39pm UTC](https://forum.syncthing.net/t/yet-another-syncthing-tray/8502 "2016-10-30T17:39:30Z")
**Posts on this page:** 20
**Page:** 11
### Author:  [@Martchus](https://forum.syncthing.net/u/Martchus)
#### Post date: [March 6, 2024, 11:09pm UTC](https://forum.syncthing.net/t/yet-another-syncthing-tray/8502/207 "2024-03-06T23:09:54Z")
> [@jackdinn](#):
>
> After update 1.5.0 The GUI has changed (on KDE) to what looks to be an older GUI and i can not figure how to get it back
You need to install `syncthingtray-qt6` (and may uninstall `syncthingtray`) as I mentioned in my last summary about recent changes in this forum thread. Checkout the remarks in the pinned comments on the AUR for further details.
And yes, this is about the Plasmoid vs. the stand-alone version. Checkout the [according README section](https://github.com/Martchus/syncthingtray/blob/master/README.md#configuring-plasmoid) for details.
> [@jackdinn](#):
>
> I dont really want to uninstall and reinstall because im not sure i want to set it all up again (if i can remember how).
That’s fortunately not how it works. When uninstalling a package of a GUI application like Syncthing Tray the configuration is not lost. So when installing the package again you won’t have to reconfigure anything. This also counts for switching from `syncthingtray` to `syncthingtray-qt6` except that you’ll have to remove the “old” Plasmoid and add the new Plasmoid because for Plasma these are distinct Plasmoids. Removing/re-adding the Plasmoid does _not_ reset the overall configuration so this is not a big deal. Again, checkout the [README](https://github.com/Martchus/syncthingtray/blob/master/README.md#location-of-the-configuration-file) for details.
---
### Author:  [@jackdinn](https://forum.syncthing.net/u/jackdinn)
#### Post date: [March 6, 2024, 11:20pm UTC](https://forum.syncthing.net/t/yet-another-syncthing-tray/8502/208 "2024-03-06T23:20:04Z")
Hmm, what am i doing wrong? why cant i reach/resolve
```plaintext
:: (27/40) Failed to download PKGBUILD: kcmutils-git
:: (27/40) Failed to download PKGBUILD: upower-git
:: (27/40) Failed to download PKGBUILD: qtforkawesome-qt6
:: (27/40) Failed to download PKGBUILD: kirigami-git
-> error fetching kauth-git: Cloning into 'kauth-git'...
fatal: unable to access 'https://aur.archlinux.org/kauth-git.git/': Could not resolve host: aur.archlinux.org
context: exit status 128
error fetching knotifications-git: Cloning into 'knotifications-git'...
fatal: unable to access 'https://aur.archlinux.org/knotifications-git.git/': Could not resolve host: aur.archlinux.org
context: exit status 128
error fetching kiconthemes-git: Cloning into 'kiconthemes-git'...
fatal: unable to access 'https://aur.archlinux.org/kiconthemes-git.git/': Could not resolve host: aur.archlinux.org
context: exit status 128
error fetching kdoctools-git: Cloning into 'kdoctools-git'...
fatal: unable to access 'https://aur.archlinux.org/kdoctools-git.git/': Could not resolve host: aur.archlinux.org
context: exit status 128
error fetching kguiaddons-git: Cloning into 'kguiaddons-git'...
fatal: unable to access 'https://aur.archlinux.org/kguiaddons-git.git/': Could not resolve host: aur.archlinux.org
context: exit status 128
error fetching kdbusaddons-git: Cloning into 'kdbusaddons-git'...
fatal: unable to access 'https://aur.archlinux.org/kdbusaddons-git.git/': Could not resolve host: aur.archlinux.org
context: exit status 128
error fetching kcrash-git: Cloning into 'kcrash-git'...
fatal: unable to access 'https://aur.archlinux.org/kcrash-git.git/': Could not resolve host: aur.archlinux.org
context: exit status 128
error fetching karchive-git: Cloning into 'karchive-git'...
fatal: unable to access 'https://aur.archlinux.org/karchive-git.git/': Could not resolve host: aur.archlinux.org
context: exit status 128
error fetching kwidgetsaddons-git: Cloning into 'kwidgetsaddons-git'...
fatal: unable to access 'https://aur.archlinux.org/kwidgetsaddons-git.git/': Could not resolve host: aur.archlinux.org
context: exit status 128
error fetching kcmutils-git: Cloning into 'kcmutils-git'...
fatal: unable to access 'https://aur.archlinux.org/kcmutils-git.git/': Could not resolve host: aur.archlinux.org
context: exit status 128
error fetching upower-git: Cloning into 'upower-git'...
fatal: unable to access 'https://aur.archlinux.org/upower-git.git/': Could not resolve host: aur.archlinux.org
context: exit status 128
error fetching qtforkawesome-qt6: Cloning into 'qtforkawesome-qt6'...
fatal: unable to access 'https://aur.archlinux.org/qtforkawesome-qt6.git/': Could not resolve host: aur.archlinux.org
context: exit status 128
error fetching kirigami-git: Cloning into 'kirigami-git'...
fatal: unable to access 'https://aur.archlinux.org/kirigami-git.git/': Could not resolve host: aur.archlinux.org
context: exit status 128
```
I do use adguard on my server for DNS, maybe something to do with that ? I would doubt it though.
---
### Author:  [@Martchus](https://forum.syncthing.net/u/Martchus)
#### Post date: [March 6, 2024, 11:38pm UTC](https://forum.syncthing.net/t/yet-another-syncthing-tray/8502/209 "2024-03-06T23:38:52Z")
`k…-git` packages are _not_ expected to be required. Could it be that Manjaro is not yet providing KDE 6 packages (so you’re still using Plasma 5)? Note that Manjaro is _not_ supported by the AUR and using it nevertheless is asking for trouble as packages in Manjaro might be too old. I suppose in this case you can mitigate the problem by staying with `syncthingtray` as long as Manjaro is still only providing KDE 5. To still build KDE integrations as part of `syncthingtray` you need to add the following to `/etc/makepkg.conf`:
```plaintext
SYNCTHING_TRAY_ENABLE_KIO_PLUGIN=1
SYNCTHING_TRAY_ENABLE_PLASMOID=1
```
(But the DNS-related errors are of course something you’ll have to figure out regardless of this explanation.)
---
### Author:  [@jackdinn](https://forum.syncthing.net/u/jackdinn)
#### Post date: [March 7, 2024, 1:13am UTC](https://forum.syncthing.net/t/yet-another-syncthing-tray/8502/210 "2024-03-07T01:13:23Z")
Thx, it started working (resolving) about an hour later but i can not install syncthingtray-qt6 , i have tried and tried but i just get a lof of dependency errors and then after about half an hour of shell text going by it just fails.
I can show the last part as a screen shot (sorry but it was such a long installation attempt each time (and i tried many times) that i just used screen shots)
It has maybe 20-30 “ERROR: Could not resolve all dependencies.” with the error in the screen shot at the end.
I have given up, From what you say it sounds like im not even supposed to be trying unless i really know what im doing (and i dont ^^).
I shall just live with the stand-alone GUI (if i havent really messed up my system, lol).
Thx for the support though.
---
### Author:  [@Martchus](https://forum.syncthing.net/u/Martchus)
#### Post date: [March 7, 2024, 1:16am UTC](https://forum.syncthing.net/t/yet-another-syncthing-tray/8502/211 "2024-03-07T01:16:01Z")
> [@jackdinn](#):
>
> but i can not install syncthingtray-qt6
Like I said before, you need to keep using `syncthingtray` for the time being (in the way I described in my last reply).
---
### Author:  [@jackdinn](https://forum.syncthing.net/u/jackdinn)
#### Post date: [March 7, 2024, 1:20am UTC](https://forum.syncthing.net/t/yet-another-syncthing-tray/8502/212 "2024-03-07T01:20:56Z")
> [@Martchus](#):
>
> (in the way I described in my last reply).
I understood, i shall leave it for tonight though. Its been a long day trying to figure this thing alone. I shall start again in the morning with your settings in the makepkg.
Have a good evening 🙂
---
### Author:  [@jackdinn](https://forum.syncthing.net/u/jackdinn)
#### Post date: [March 7, 2024, 3:53pm UTC](https://forum.syncthing.net/t/yet-another-syncthing-tray/8502/213 "2024-03-07T15:53:47Z")
> [@Martchus](#):
>
> To still build KDE integrations as part of `syncthingtray` you need to add the following to `/etc/makepkg.conf`:
>
> ```plaintext
> SYNCTHING_TRAY_ENABLE_KIO_PLUGIN=1
> SYNCTHING_TRAY_ENABLE_PLASMOID=1
>
> ```
Ok i grabbed a little time this afternoon and used your suggestion to still use kde5 by altering the makepkg.conf
It worked fine, thank you 🙂
---
### Author:  [@Martchus](https://forum.syncthing.net/u/Martchus)
#### Post date: [May 22, 2024, 2:05pm UTC](https://forum.syncthing.net/t/yet-another-syncthing-tray/8502/214 "2024-05-22T14:05:02Z")
It is a while ago since my last update, so here a few developments:
- The previously mentioned Windows 11 style can now be selected in the latest release.
- I setup a [website](https://martchus.github.io/syncthingtray). It doesn’t contain much information on its own. The main reason for creating it is the downloads section which will make it hopefully much easier to find the most relevant download for one’s platform.
- A Flatpak has been created (by [qgymib](https://github.com/qgymib)). It doesn’t contain the KDE integrations, though (because that’s not possible).
- I’m currently working on a way to ease managing ignore patterns. For this I have already created a file browser that shows the directory tree from the Syncthing database plus what is actually present on the local system. I hope I’ll be able to make it easy to add/remove paths to ignore/unignore via this UI. You can access/test the WIP file browser by setting the environment variable `SYNCTHINGTRAY_ENABLE_WIP_FEATURES=1`.
---
### Author:  [@Martchus](https://forum.syncthing.net/u/Martchus)
#### Post date: [August 7, 2024, 9:36pm UTC](https://forum.syncthing.net/t/yet-another-syncthing-tray/8502/215 "2024-08-07T21:36:59Z")
I released a new version today (1.6.0) and it contains many changes under the hood to reduce CPU usage.
The previously mentioned feature about ignore patterns is also no longer hidden behind a feature-flag. It still needs improvements in several areas but what is there should generally work (even though the UI is quite clunky at this point).
There were also changes regarding the Windows builds recently: They use mingw-w64 12 as of 1.6.0 and with that also the Universal CRT instead of the legacy one. I think this is only problematic if you use a system older than Windows 10 where you might need to [install it](https://learn.microsoft.com/en-us/cpp/windows/universal-crt-deployment?view=msvc-170#central-deployment). The builds are also conducted using the latest GCC. This also means that Qt 6 now finally doesn’t build for 32-bit Windows anymore so I dropped those builds as of version 1.5.3. (There are still 32-bit Windows builds of the version using Qt 5.)
That are all-in-all quite a few changes so let me know if something broke now (by filing an issue on GitHub).
---
### Author:  [@Martchus](https://forum.syncthing.net/u/Martchus)
#### Post date: [November 1, 2024, 1:22am UTC](https://forum.syncthing.net/t/yet-another-syncthing-tray/8502/216 "2024-11-01T01:22:07Z")
It looks like the previously mentioned changes all worked out well without any notable regressions.
Here again a small update:
- The last update brought a better UI for showing notifications and suppressing “Disconnect” notifications on Windows when resuming from standby.
- The next version will render the folder/devices tree a bit differently so it looks much better when long folder labels are used.
- I’m currently working on [Android integration](https://forum.syncthing.net/t/discontinuing-syncthing-android/23002).
---
### Author:  [@Martchus](https://forum.syncthing.net/u/Martchus)
#### Post date: [November 25, 2024, 3:55pm UTC](https://forum.syncthing.net/t/yet-another-syncthing-tray/8502/217 "2024-11-25T15:55:06Z")
It looks like I’ll be able to provide Windows builds for ARM as of the next release by cross-compiling them.
So far I was only able to test the build via WINE and CPU emulation as I don’t have such an ARM Windows system. Within this test setup it generally works. If anyone who is interested can test on a real system and wants to help with testing, here is a link to a development build: [https://martchus.dyn.f3l.de/repo/arch/ownstuff-experimental/os/x86\_64/mingw-w64-clang-aarch64-syncthingtray-qt6-1.6.4-1-any.pkg.tar.zst](https://martchus.dyn.f3l.de/repo/arch/ownstuff-experimental/os/x86_64/mingw-w64-clang-aarch64-syncthingtray-qt6-1.6.4-1-any.pkg.tar.zst) (use the `-static` executable)
The only limitation I am aware of so far is that I couldn’t compile/use Boost.Process (because its dependency Boost.Context is not supported on `aarch64-w64-mingw32` yet). That means stopping Syncthing via the launcher forcefully might not cleanly terminate all processes. (Stopping Syncthing when the built-in Syncthing library is used is not affected and will work properly.)
---
### Author:  [@Martchus](https://forum.syncthing.net/u/Martchus)
#### Post date: [December 3, 2024, 7:53pm UTC](https://forum.syncthing.net/t/yet-another-syncthing-tray/8502/218 "2024-12-03T19:53:35Z")
> [@Martchus](#):
>
> It looks like I’ll be able to provide Windows builds for ARM as of the next release by cross-compiling them.
An ARM binary is now available for Windows.
> [@Martchus](#):
>
> So far I was only able to test the build via WINE and CPU emulation as I don’t have such an ARM Windows system. Within this test setup it generally works. If anyone who is interested can test on a real system and wants to help with testing, here is a link to a development build: [https://martchus.dyn.f3l.de/repo/arch/ownstuff-experimental/os/x86\_64/mingw-w64-clang-aarch64-syncthingtray-qt6-1.6.4-1-any.pkg.tar.zst](https://martchus.dyn.f3l.de/repo/arch/ownstuff-experimental/os/x86_64/mingw-w64-clang-aarch64-syncthingtray-qt6-1.6.4-1-any.pkg.tar.zst) (use the `-static` executable)
>
> The only limitation I am aware of so far is that I couldn’t compile/use Boost.Process (because its dependency Boost.Context is not supported on `aarch64-w64-mingw32` yet). That means stopping Syncthing via the launcher forcefully might not cleanly terminate all processes. (Stopping Syncthing when the built-in Syncthing library is used is not affected and will work properly.)
It generally works on a real device. Problems are currently discussed [on GitHub](https://github.com/Martchus/syncthingtray/issues/218).
---
### Author:  [@theAeon](https://forum.syncthing.net/u/theAeon)
#### Post date: [December 27, 2024, 2:23pm UTC](https://forum.syncthing.net/t/yet-another-syncthing-tray/8502/219 "2024-12-27T14:23:45Z")
Currently trying to get a debug build up and running on my ARM laptop as i mentioned earlier-how are you getting it to compile w/ all the dlls statically linked? Struggling a little bit.
---
### Author:  [@Martchus](https://forum.syncthing.net/u/Martchus)
#### Post date: [December 27, 2024, 2:47pm UTC](https://forum.syncthing.net/t/yet-another-syncthing-tray/8502/220 "2024-12-27T14:47:02Z")
I recommend using MSYS2 and dynamic linking for development/debugging on Windows itself.
The release binaries provided by me for Windows are built on Arch Linux (x86\_64) using LLVM/Clang and Go as provided by Arch Linux. There I cross compiled all dependencies from scratch (including mingw-w64, the LLVM compiler runtime and libc++ but also Boost, Qt and many more). I also created static builds of those libraries allowing me to create a self-contained binary. The build scripts I am using are present in form of Arch Linux PKGBUILDs on [GitHub - Martchus/PKGBUILDs: PKGBUILDs for creating various Arch Linux packages (including lots of mingw-w64 cross compiler packages)](https://github.com/Martchus/PKGBUILDs).
---
### Author:  [@theAeon](https://forum.syncthing.net/u/theAeon)
#### Post date: [December 27, 2024, 3:56pm UTC](https://forum.syncthing.net/t/yet-another-syncthing-tray/8502/221 "2024-12-27T15:56:23Z")
ah-gotcha. I am using msys2/clang-aarch64, so I’ll just copy the libraries. Will report back when I get a trace.
---
### Author:  [@Martchus](https://forum.syncthing.net/u/Martchus)
#### Post date: [December 27, 2024, 4:14pm UTC](https://forum.syncthing.net/t/yet-another-syncthing-tray/8502/222 "2024-12-27T16:14:05Z")
I usually add the relevant bin directory of MSYS2 to the PATH and also set QT\_PLUGIN\_PATH accordingly to avoid copying. When you also build Syncthing Tray (and my other libraries via the subdirs project) as static libraries (the default) then no copying should be necessary.
(Just be careful with the plug-in path as it affects all Qt apps using dynamic libraries, see [https://doc.qt.io/qt-6/deployment-plugins.html.](https://doc.qt.io/qt-6/deployment-plugins.html.))
When reporting back the trace, also say what build config you ended up doing (e.g. whether Boost.Procces and the internal Syncing library were enabled) and how you configured Syncthing Tray.
---
### Author:  [@theAeon](https://forum.syncthing.net/u/theAeon)
#### Post date: [December 27, 2024, 5:35pm UTC](https://forum.syncthing.net/t/yet-another-syncthing-tray/8502/223 "2024-12-27T17:35:18Z")
So, I did manage to get it running (manual copy + windeployqt6 because I didn’t see this until afterwards) and…it runs. Unless I launch it with a debugger. Or attach a debugger to it and click the tray icon. Then it gives me
```plaintext
* thread #1, stop reason = Exception 0xc00000ff encountered at address 0x7ffc8cf02710
* frame #0: 0x00007ffc8cf02710 ntdll.dll`RtlRaiseStatus + 64
frame #1: 0x7e49fffc8cf03f78
```
with…no elaboration whatsoever.
windbg is a bit more informative
edit: would probably help if i built the syncthing library in
edit edit: it actually works now. still explodes when i attach a debugger and click the tray icon but i can simply not click the tray for now
---
### Author:  [@Cutter](https://forum.syncthing.net/u/Cutter)
#### Post date: [June 21, 2025, 5:32pm UTC](https://forum.syncthing.net/t/yet-another-syncthing-tray/8502/224 "2025-06-21T17:32:48Z")
Hello, Is there a french translation ? If not, I can help.
---
### Author:  [@Martchus](https://forum.syncthing.net/u/Martchus)
#### Post date: [June 21, 2025, 5:53pm UTC](https://forum.syncthing.net/t/yet-another-syncthing-tray/8502/225 "2025-06-21T17:53:07Z")
There is no French localization. PRs adding more translations are generally welcome.
This is my most recent update on translations: [Localization to other languages · Issue #340 · Martchus/syncthingtray · GitHub](https://github.com/Martchus/syncthingtray/issues/340#issuecomment-2886291938)
---
### Author:  [@Martchus](https://forum.syncthing.net/u/Martchus)
#### Post date: [July 3, 2025, 12:59am UTC](https://forum.syncthing.net/t/yet-another-syncthing-tray/8502/226 "2025-07-03T00:59:33Z")
The next release contains an experimental updater. So you can enable automatic checks for new versions in the settings and if there’s a new version you’ll also be able to update to the new version directly. So this is similar to Syncthing’s own updater.
It worked well in my tests but of course all tests so far had to have some kind of mocking involved. Let’s see how well it works once everything is actually in place. Somehow I suspect that in practice known issues like with Windows SmartScreen and certain Anti-Virus scanners will interfere with the updating on Windows.
The archives on GitHub now contain signature files for the executables. Those are used internally by the new updater to verify whether the executable is valid. For manual validation you should probably still use the GPG-based signing which is still present as before.
The executables are now also no longer containing the version and platform because this makes more sense for the automatic updating. Probably most people were renaming the executable to remove the version and platform anyway. This way it is also in-line with how Syncthing itself does it.
For those curious about the new signature files: The signatures are created using `stsigtool` and verified by the updater using the Go code from Syncthing just like the official updater of Syncthing. So if you wanted to verify with these signature files manually you could use `stsigtool` (which can be found in the Syncthing repo on GitHub) and the public key [which is currently hardcoded in code](https://github.com/Martchus/syncthingtray/blob/b704cdefdaf90d44b996cf0919ea2e47ae81d536/tray/application/main.cpp#L117). The aarch64 builds for Windows have the built-in Syncthing library disabled as using Go as a library on that platform is not stable yet. Hence those builds use OpenSSL-based signature verification instead. This is the reason why there is a 2nd signature file. (I could not make it work with just one keypair and thus also only one signature. It seems that `stsigtool` and the Go code behind it is not compatible with OpenSSL - even though I really tried hard to get the details on the OpenSSL-side as code as possible to what `stsigtool` does.)
[Previous page](https://forum.syncthing.net/t/yet-another-syncthing-tray/8502.md?page=10)
[Next page](https://forum.syncthing.net/t/yet-another-syncthing-tray/8502.md?page=12)