Ask HN: Smoothness and performance of Qt based systems vs. native apps and OS

Why?

  > "That's like saying Java's a native SDK for Windows or macOS or Linux."

Not an unreasonable claim if you're packaging with Graal's native-image tbh.

Dotnet has NativeAOT, and JVM languages have GraalVM (with Kotlin Native too for Kotlin, and Scala Native too for Scala).

What you get when building an application with Dotnet Native, GraalVM native-image, Kotlin Native, Scala Native, etc, is architecture-dependent native code identical to compiling with "CC myfile.cpp"

So I don't find that unreasonable tbh.

If I can use NativeAOT/Dotnet Native Exports on .NET/GraalVM on the JVM to do this, as well as export a static/dynamic lib with a C ABI that I can use on whatever OS from C/C++/Rust code or whatever, I really don't know what else you need to call something "native" tbh.

It's a lot more complicated than that. I'm speaking from experience with Qt 5.14-15 and Qt 6.

Qt 5 defaults to "DPI scaling off", where text is enlarged but 1px is always 1px regardless of the current scale (so UI elements sized in px can end up too small on HiDPI displays). It has a mode with DPI scaling on, where 1px could be a fractional or integer number of on-screen pixels. Qt 6 only supports this latter mode.

Qt 5 defaults to rounding the magnification factor (output physical pixels / input program-facing virtual pixels) to an integer (except on KDE where it's passed through), while Qt 6 defaults to passing it through as a real number. (Qt 5.14+ and Qt 6 allow apps to customize what rounding method is used, except on KDE where it's passed through no matter what your app requests.) Passing through non-integer scale factors causes Qt's Windows-style theme (and some apps as well) to break spectacularly with rounding errors left and right, shifting as you move your mouse and focus between widgets. Breeze and Fusion handle this better (in my opinion using hacks rather than logical principled fixes), but I still prefer integer scale factors where I'm guaranteed that each x-by-y rectangle is the same integer number of on-screen pixels (which is useful for creating correctly sized off-screen buffers and blitting regions between graphical buffers).

All in all, if you drag a window between screens, Qt apps should handle it mostly fine. However, Qt doesn't properly respond when a display changes scale factor (like switching from laptop-only to external-only, or changing the scale factor of a monitor for testing), because Qt only checks for scale factor changes when the screen ID changes.

Unfortunately Qt makes it hard for apps to properly handle changing scale factors. If you cache the size of text in pixels, or "64 px * current scale factor", then the app changes scale factors, the app will resize, but your cached sizes won't change. I think property binding is a good solution to this (easier to use than Qt's private events, or handling QScreen-changed or QScreen-property-changed signals), but Qt isn't currently built around property binding. Maybe in a few years, Qt 6 will port the long tail of APIs to QProperty... I can only hope...

(Also Qt Creator's "new file" wizard somehow managed to have broken layout (too-small QLineEdit text fields) even when opening the app on a constant non-changing 125% scale. I suspect it's related to constructing a QFont without passing in a widget for context, causing it to use the global scaling instead of the current window's scaling. Or maybe it's because on Qt 5, Qt defaults to something like unscaled MS Shell Dlg 2 rather than scaled lfMessageFont.)

KDE does have a long tail of (more or less maintained) apps, but there's nothing stopping you from installing the WM and plasmashell alone, along with a small selection of apps like Dolphin and Konsole. (You will spend a lot of disk space on KF5, and you might want to avoid Akonadi-based PIM apps too.) Do you think KWin/plasmashell is bad software (admittedly KWin has bugs, and plasmashell is worse off for being based off QML/JS and using janky drag-drop interfaces instead of traditional widgets), or are you avoiding it just because developers spend effort on apps?

You could try liquidshell as a plasmashell replacement, but I didn't like it (can't right-click to customize the panel, no Windows 7 style taskbar-dock IIRC).

There's Deepin too, but that's developed in China (which might be fine) and comes with a suite of applications (you probably won't like it either). I don't understand why you're fine with GNOME or XFCE though, since they also come with a suite of applications (GNOME has a file manager, text editor, terminal, IDE, browser, and VM GUI, and XFCE has a file manager, text editor, and terminal).

Even on a very powerful modern machine you could probably tell the difference by looking at "abnormal" RAM usage.

Are that many KDE apps using QML (as opposed to qwidgets), though? Or does parent remark apply to both?