[jcelerier]

If you use Qt the framework does its best to make sure the native thing will be used where appropriate. QtCore, Gui and Widgets is like 15 megabytes total and that will already allow 90% of Qt apps to run. A bazillion packages being installed if you want to install one Qt app is just the fault of your distro's policies on how software should be distributed

[rollcat]

> the fault of your distro's policies

Yeah, about that... fracturing at every possible level.

- Linux vs Free/Open/Net/Dragonfly BSD

- Linux distro 1 vs X vs A vs Ω vs ...

- glibc (with all its warts like versioned symbols) vs musl vs BSD libc

- systemd vs sysvinit vs rc vs OpenRC vs daemontools/s6/runit/...

- Who "owns" /etc/resolv.conf?

- apt vs (yum / dnf) vs pacman vs apk vs xbps vs emerge vs ...

- Flatpak vs Snap vs AppImage

- X11 (and libx11 vs xcb) vs Wayland (which protocols/extensions are supported?)

- OSS vs ALSA vs PulseAudio vs Pipewire vs sndiod vs ...

- Gtk (2/3/4) (with Gnome or without) vs Qt (with KDE or without) vs Tk vs direct X11 vs SDL/glfw/... vs an obscure toolkit last updated 15 years ago

inb4 it's about choice, the heck I'm supposed to choose as an app developer? inb4 "follow the standard", half of these are not standardised but still in widespread use? inb4 distro policies, which distro - top 10 on distrowatch looks like more work than macOS+Windows combined? Delegate to package maintainers, and my app is "fixed"/patched beyond me being able to debug/support? I choose what seems to work (for example, escaping via the XDG portal) and I'm getting rug-pulled?

This is exactly why we can't have nice things.

[jcelerier]

As an app developer, I ship an appimage and a flatpak based on Qt and things generally work as expected. Supporting macOS which drops compatibility with random things every other version all while providing a super old Clang is in practice much more painful.