4 ms·

> In reality, if you want to actually make a serious, usable and comfortable GUI, there is no cross-platform solution Qt? Tk? I've used both cross-platform a

> In reality, if you want to actually make a serious, usable and comfortable GUI, there is no cross-platform solution Qt? Tk? I've used both cross-platform and both work great for desktop operating systems (and unlike in the olden days, Tk's themed widgets actually look reasonably native now). Qt's only downside is the licensing and the sheer size of it, and Tk's only downside (for my use cases) is the lack of an embeddable browser widget; in both cases these are issues regardless of platform. The actual cross-platform issues, from what I've seen, are more to do with the non-GUI pieces. For example, Windows and macOS/Linux printing are wildly different from one another, and all three operating systems have wildly different strategies for packaging and distributing applications (especially when writing the program in a scripting language like Python or Ruby or what have you instead of something precompiled like C++ or Rust; with Linux this is trivial, and with macOS this is less trivial but manageable, but with Windows this is a royal pain in the ass). On another note, I'm currently looking into Avalonia and .NET Core as another potential option in this space; from preliminary testing, .NET Core looks like it mostly addresses the issues I've encountered (it certainly makes it easy to cross-compile for Windows/Mac/Linux, and I'm hoping it'll eventually subsume Xamarin or portions thereof to enable easy Android and iOS builds, too), so whether or not this becomes my go-to hinges on whether or not Avalonia itself is ready for primetime (and while simple examples seem to be promising, as are more complex examples like the Avalonia version of ILSpy, I'm still actively investigating).

DagAgren 7y ago
Neither of those are anywhere near good enough. "Looking reasonably native" is miles away from the goal.
- jcelerier 7y ago
  They are obviously good enough for a ton of software
- yellowapple 7y ago
  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.
  - DagAgren 7y ago
    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.
    - yellowapple 7y ago
      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). ---- ¹: https://doc.qt.io/qt-5/accessible.html https://doc.qt.io/qt-5/accessible.html

DagAgren 7y ago

Neither of those are anywhere near good enough. "Looking reasonably native" is miles away from the goal.

jcelerier 7y ago
They are obviously good enough for a ton of software
yellowapple 7y ago
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.
- DagAgren 7y ago
  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.
  - yellowapple 7y ago
    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). ---- ¹: https://doc.qt.io/qt-5/accessible.html https://doc.qt.io/qt-5/accessible.html