Strange, maybe the non-integer scale factor is an issue in the Qt 5 version. I sometimes used it on a 4k display with integer scale factors and the Qt 5 version scaled everything including fonts. The only problem was when the scaling was changed after the application has already started.
This may be the case, although I have not tested other scale factors. I would only like to add that the same behaviour persists in Windows 10, so this difference has nothing to do with Windows 7 per se.
I’ve tried all of them and they all look exactly the same. I think the note at the bottom explains this behavior: “These settings might be overwritten by your Qt platfrom integration plugin and hence have no effect.”
Font and size do not affect this “bold” rendering.
Not on my system:
as you can see, Qt5 rendering is almost identical to the native one. But Qt6 contains some artifacts:
some lines are missing, elements that should be identical are different, up/down and scrollbars look very strange.
Thanks for your feedback. Unfortunately I can not do much about these issues and my knowledge of Qt’s internals and changes of Qt 6 is also limited. I mainly asked for feedback to decide which Qt version to use for my binaries. For now I decided to keep using Qt 5 and add Qt 6 based binaries only additionally.
By the way, I’ve also noticed a slightly different font rendering when testing myself under Windows 10. What you describe as “bold” looks like anti-aliasing to me but it really doesn’t look very good in your case.
I’d also like to note that the latest Qt 5 and Qt 6 based binaries are linked against the exact same versions of FreeType2 and Harfbuzz (and any other dependency). My own code is also almost identical. So I really suspect the Qt version makes the difference here. Maybe also just some default settings (which my code doesn’t touch) have changed.
Thank you for this decision. I think as long as Qt5 is Windows10 compatible, there is no point in upgrading to Qt6.
I know nothing about Qt, but maybe this information will help somehow:
New Features in Qt 6.0
Qt High DPI scaling is now activated by default; the default rounding policy is PassThrough
Integer scale factors (e.g. 1.0 or 2.0) are preferred for best results. “Rounding” the scale factor to 25% increments can also give good results. Setting the scale factor or DPI to the exact physical display DPI may not give good visual results due to the fractional scaling involved. If the application suffers from visual artifacts in this scenario, it can use QGuiApplication::setHighDpiScaleFactorRoundingPolicy() to limit the scale factors it will see.
1 Like
I could reproduce the glitches under Windows 10 and also under X11/Linux when setting the environment variable QT_SCALE_FACTOR to a non-integer value like 1.25. And it is only reproducible when using Qt 6. So likely the different default for the rounding policy in Qt 6 makes indeed the difference here because Syncthing Tray simply uses Qt’s default here.
In Qt 5 the default could be overridden by setting QT_SCALE_FACTOR_ROUNDING_POLICY=Round|Ceil|Floor|RoundPreferFloor|PassThrough but judging by the documentation that’s no longer the case for Qt 6 (compare https://doc.qt.io/qt-5/qguiapplication.html#setHighDpiScaleFactorRoundingPolicy with https://doc.qt.io/qt-6/qguiapplication.html#setHighDpiScaleFactorRoundingPolicy). However, judging by the code it is actually still possible.
I’ve also just tested it on Linux but it didn’t make much of a difference. In fact, regardless of what I set QT_SCALE_FACTOR_ROUNDING_POLICY to I’m getting the same rendering issues. However, the environment variable seems to be parsed at least, e.g. I’m getting Unknown scale factor rounding policy: loor. Supported values are: Round, Ceil, Floor, RoundPreferFloor, PassThrough. if I pass a wrong value.
2 Likes
Bingo! QT_SCALE_FACTOR_ROUNDING_POLICY=Round removes all glitches.
QT_SCALE_FACTOR=0.8 (0.8*1.25=1.0) also removes them, but UI is too small.
1 Like
Glad to hear. (Maybe it didn’t make a difference in my tests to set QT_SCALE_FACTOR_ROUNDING_POLICY because I also set QT_SCALE_FACTOR to enforce a certain scale factor as the default on this system is simply 1.)
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