If looking reasonably native is indeed "miles away from the goal", then I'd argue the goal betrays excessive and needless attention to pixel perfection instead of more important things like, you know, the actual functionality of the app. No user would even notice these differences (let alone complain about them) unless they were both really savvy and really nitpicky.
Comparing Qt v. Tk v. native on Windows and macOS (and Linux, but there is no "native" toolkit so there wasn't anything to compare), not once did I notice any actual significant difference. macOS is the only one that required the slightest bit of adjustment (for the stuff I wrote; no idea about the Qt or Tk programs others wrote), and that's only to make sure it uses the system menu bar instead of shoving one into the top of the window as is normal for Windows and (usually) Linux.
It is not "pixel perfection". It is many things besides, such as behaviours, generally agreed-upon layouts, spacings and margins, accessibility, the list goes on and on and on.
I have not seen a Qt app on macOS that did not stand out like a sore thumb on the very first glance.
I'd say "spacings and margins" fall into the "pixel perfection" category for pretty obvious reasons.
Divergence in "behaviours" and "generally agreed-upon layouts" is possible even with native toolkits, so I fail to see how Qt or Tk are a relevant factor here (both of them give the programmer the necessary tools to match the native behavioral and layout conventions, just like the native toolkits do).
Tk definitely has a disadvantage in the "accessibility" category, but Qt literally uses and abstracts the native accessibility interfaces¹, so in Qt's case this should be a non-issue (beyond the typical considerations for software accessibility that apply even for native toolkits, like, you know, actually leveraging and testing those features).
I have not seen a Qt app on macOS that did not stand out like a sore thumb on the very first glance.
Okay, but by virtue of knowing what Qt even is, I'd wager that you ain't an ordinary user. The vast majority of end users will neither notice nor care (especially given that there's an abundance of commonly-used software that deviates from the typical macOS UX even without Qt, e.g. Office and Chrome, or pretty much every single app using Electron or CEF or some other browser-as-UI approach). The only thing that truly matters is whether or not the software works and is usable, and Qt doesn't really pose any obstacle there (and Tk only does if accessibility is a concern - which I'd argue it should be, but it's at least no worse than the status quo).
Comments
If looking reasonably native is indeed "miles away from the goal", then I'd argue the goal betrays excessive and needless attention to pixel perfection instead of more important things like, you know, the actual functionality of the app. No user would even notice these differences (let alone complain about them) unless they were both really savvy and really nitpicky.
Comparing Qt v. Tk v. native on Windows and macOS (and Linux, but there is no "native" toolkit so there wasn't anything to compare), not once did I notice any actual significant difference. macOS is the only one that required the slightest bit of adjustment (for the stuff I wrote; no idea about the Qt or Tk programs others wrote), and that's only to make sure it uses the system menu bar instead of shoving one into the top of the window as is normal for Windows and (usually) Linux.
It is not "pixel perfection". It is many things besides, such as behaviours, generally agreed-upon layouts, spacings and margins, accessibility, the list goes on and on and on.
I have not seen a Qt app on macOS that did not stand out like a sore thumb on the very first glance.
I'd say "spacings and margins" fall into the "pixel perfection" category for pretty obvious reasons.
Divergence in "behaviours" and "generally agreed-upon layouts" is possible even with native toolkits, so I fail to see how Qt or Tk are a relevant factor here (both of them give the programmer the necessary tools to match the native behavioral and layout conventions, just like the native toolkits do).
Tk definitely has a disadvantage in the "accessibility" category, but Qt literally uses and abstracts the native accessibility interfaces¹, so in Qt's case this should be a non-issue (beyond the typical considerations for software accessibility that apply even for native toolkits, like, you know, actually leveraging and testing those features).
Okay, but by virtue of knowing what Qt even is, I'd wager that you ain't an ordinary user. The vast majority of end users will neither notice nor care (especially given that there's an abundance of commonly-used software that deviates from the typical macOS UX even without Qt, e.g. Office and Chrome, or pretty much every single app using Electron or CEF or some other browser-as-UI approach). The only thing that truly matters is whether or not the software works and is usable, and Qt doesn't really pose any obstacle there (and Tk only does if accessibility is a concern - which I'd argue it should be, but it's at least no worse than the status quo).
----
¹: https://doc.qt.io/qt-5/accessible.html