You right. Comment from qhighdpiscaling.cpp:
Note that the OS scale factor, and global scale factors set with QT_SCALE_FACTOR are never rounded by Qt.
1 Like
Just for the record, I am running the new release in its Qt 6 incarnation under Windows 10, and one thing to say is that the popup window when clicking on the tray icon is now HUGE. Horizontally, it takes almost half of my 1920x1200 screen. While I do like the larger text scaled up to the system DPI everywhere, the gigantic size of the popup makes me want to stick to the Qt 5 version.
I haven’t noticed that but there’s also no scaling involved on my Windows setup. We’ve already seen that the scaling makes a difference here. Note that it is actually wanted that the popup Window is rendered e.g. twice as big if Qt generally scales by this factor (e.g. via QT_SCALE_FACTOR=2). You could try to make it smaller within the settings. The figures for width and height in the settings are unscaled and are supposed to be multiplied by the scale factor.
1 Like
Never mind. Long ago I had increased the original values when using the Qt 5 version, and then completely forgot that you could actually adjust them 
.
Now those custom values have got scaled to the system DPI in Qt 6, hence the huge increase in size.
Hi @Martchus ,
First of all, thanks for your work, I found your wrapper implementation to be very useful 
I’ve noticed that there AppImage artifacts aren’t included anymore with newer releases (v1.1.1 and v1.1.2), only windows and source packages are present among the assets.
Looking at the openSUSE build service page, it looks like the listed version is old, but the date corresponds with the newer releases…
What is the plan around binary releases for Linux (in particular for Debian-based distros)? Do you plan to continue shipping in AppImage format, or replace it with something else, or just supply the sources to be manually compiled?
I’m usually not adding the AppImage immediately because I’ll have to wait for OBS to actually build it. That might be delayed further if there are build issue. Therefore I’ve also skipped the last release entirely. I’ve just been uploading the binary for the latest release.
There’s one important remark regarding the AppImage: It contains very outdated libraries and I might stop updating it at any point when it becomes unfeasible to maintain because the required build environment is too old. The AppImage is merely intended for being able to try the software out anyways. If you decide to actually use it I would recommend to take the effort to create a package/binary as appropriate for your platform.
I might replace the AppImage in the future with a self-contained binary where Qt and a few other problematic dependencies are linked-in statically. This might require a newer version of libc and the Linux kernel than the AppImage currently does but would allow to use newer versions of certain dependencies. Still, this kind of distribution is mainly focusing on the “try out” factor and not intended for permanent use.
About Debian packaging: Nothing has changed since the last updates to Create and maintain Flatpak and Debian packages · Issue #33 · Martchus/syncthingtray · GitHub. So anybody is welcome to create packages but I personally don’t care about Debian simply because I can not care about any distribution out there.
2 Likes
I am not sure why, but recently (maybe after upgrading to Syncthing 1.13.x?), I have experienced a strange problem.
Basically, my own device is being shown as “paused”.
This has happened quite a few times, so it seems to be some kind of a bug, but I am not sure how to debug this. Obviously, everything seems fine in the actual Syncthing Web GUI. Also, only one configuration behaves this way, while the other ones all seem to be working fine.
Trying to “resume” in the Syncthing Tray does nothing though. The device seems to stay “paused” permanently (even though in reality it is working just fine).
I am using Syncthing Tray (Qt 6) v1.1.2.
Since I can not reproduce it I can only go through the code to spot the mistake. The following change might help: Comparing master...fix/own-dev-paused · Martchus/syncthingtray · GitHub
I’ve created Windows binaries containing that change if you’d like to test them: https://martchus.no-ip.biz/repo/arch/ownstuff-experimental/os/x86_64/mingw-w64-syncthingtray-qt6-1.1.3-1-any.pkg.tar.zst
Unfortunately, there is no difference 
. The device is still listed as “paused”. One thing that I can also add is that the tray icon seems to periodically switch from grey to blue back and forth, but the status remains “paused” regardless.
Edit: In the meantime, I have tested the Qt 5 flavour of v1.1.2 too, but the problem is still there.
Does the ID shown for your own device within the list of devices match the ID shown for your device when you click on “View own device ID”?
By default the overall status is “paused” when at least on device is paused. You can disable this setting as a workaround to avoid the overall status being affected.
The ID is correct, but the last seen date is kind of suspicious.
I have just done it 
. Just for the record, I have no actual devices paused in the Web GUI. It is just Syncthing Tray that marks the “own device” as “paused”.
In both cases, including the “View own device ID” dialog?
I can reproduce the wrong/meaningless “Last seen” date here as well. Not sure whether that was always the case. Note that this date is passed as-is from Syncthing’s REST-API which apparently sets that value for the own device. Maybe I should treat that data as null-value or simply ignore the data for the own device.
Interestingly the official web UI shows “Never” as last seen date for one of my devices although the API correctly returns “2018-05-03T16:29:29.594912942+02:00”. Syncthing Tray shows as always the value from the API as-is. I’m wondering whether it makes generally sense to have a threshold like the official web UI (whatever that threshold exactly is).
I suppose it is actually impossible to pause the own device. That Syncthing Tray displays the own device as paused is definitely just a displaying error on my side and should never occur regardless of your settings.
1 Like
I think that I have found the culprit…
This comes from the config.xml of the own device.
<device id="D4DZUGP" name="XXX" compression="metadata" introducer="false" skipIntroductionRemovals="false" introducedBy="">
<paused>true</paused>
</device>
I am really not sure how this happened, but the device was indeed set to “paused”, although this should not be possible. It was still syncing fine nevertheless. I have now modified the file manually, restarted Syncthing, and now Syncthing Tray is reporting the status correctly again.
Edit: I know how this happens! In the Web GUI, if you pause everything using the “Pause All” button, but then resume each device only separately, the own device will stay “paused”.
Thanks, I suppose I can now try to reproduce the problem and possibly change Syncthing Tray to handle the configuration in a more appropriate way.
I could change Syncthing Tray to completely ignore the device being paused but considering that this is actually really just the state of the Syncthing configuration it feels a bit like lying.
You can easily resume your own device via Syncthing Tray itself to workaround the problem so I’ll wait until the issue you’ve created is resolved before doing any changes on my side.
Can you do it? I have tried, but it did not work. The status remained paused, and the config file also did not change.
Strange, I can change the paused status here. It works even when I have initially <paused>true</paused> within the Syncthing config and the status is reflected immediately and written to the config file (using Syncthing 1.13.1 under openSUSE).
Yeah, I tried multiple times, but to no avail. It only fixed itself after manually editing config.xml.
Syncthing v1.13.1 under Windows 10 here.
I am looking at setting up ST on multiple machines running Debian Buster w/ KDE as the windowing environment… I am not thrilled by having ST as one of the many tabs in my browser and would rather have a separate task for it… Is this something Syncthingtray would be good for? It looks like it from the Github page, but I am not sure.
Also is there a .deb package or other suitable ‘ready to run’ install package that is compatible w/ Debian, or do I need to figure out how to compile from source?
If syncthingtray isn’t the best choice for this, is there a better alternative?
I suppose so. Just give it a try.
There are no packages for Debian, I suggest using the AppImage to try it out and if you like it just build it yourself (see Yet another Syncthing Tray - #95 by Martchus). Note that the AppImage only features the desktop-neutral version and not the applet for the Plasma desktop.