In reality, if you want to actually make a serious, usable and comfortable GUI, there is no cross-platform solution. There are many attempts, but none will let you create a GUI that actually fulfils all those requirements.
If you are making something serious, you will have to implement at least the GUI layer separately for all platforms.
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).
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).
Why do I keep seeing people say this? People have been doing this for 30 years.
Fltk will let you do it in 700KB with no dependencies. (100KB if you're crafty). Juce, Qt, pyQt, opengl+imgui, opengl+nanogui all work well. There is also gtk, Tk, wxWindows ...
The idea isn't that you can't have some windows with text and buttons displayed with the same code on all platforms but that these windows, text and buttons wont look and behave like they are supposed to and expected by the users of each platform.
Now, outside of macOS this might not be much of a problem since Windows users were beaten into submission to accept any arbitrary look and behavior and Linux users never had a choice anyway.
"People complaining about buttons looking different" is a problem.
But it isn't just "buttons looking different", it is also "buttons behaving different". As an example (that i often find annoying in programs with long lists), under Windows Qt scrollbars do not behave like native Windows scrollbars: shift click in Windows should cause the scrollbar to scroll at the point you clicked (like middle click on most X toolkits) but Qt ignores that.
Also it is "buttons not integrating properly". On macOS it is very common for example to have system-wide addons (services i think they are called) that add additional functionality to text fields, like "search with google", "text to speech", "show definition", etc. This doesn't work when a toolkit does its own text field controls. You can also see a similar thing on Windows: GTK+ applications (e.g. GIMP) ignore the emoji panel in their text fields that appear with Windows+; but native text fields work fine with it.
Now note that i'm not saying this is something that matters for all sorts of applications or is always a deal breaker (especially nowadays that, as i wrote above, most users outside of macOS have been conditioned to accept these), but it isn't something that you can handwave away as "having a different shade" either.
Now note that i'm not saying this is something that matters for all sorts of applications or is always a deal breaker
The more serious issue that nobody here has yet mentioned is lack of accessibility, e.g. for blind users with screen readers, in many toolkits. I say that is a deal-breaker if you're developing any kind of application that someone is going to use in their job, education, or other important tasks, unless the task is already inherently visual in nature. Qt has passable accessibility on Windows, Mac,and desktop Linux. GTK is accessible as part of GNOME. Electron, for all its faults, is as accessible as Chrome (pretty good these days). FLTK, FOX, Nuklear, TK, and a thousand other toolkits have zero accessibility. I've grown weary of bringing this up, and some of you may be tired of seeing it, but I feel compelled to do everything I can to make sure nobody overlooks this point, lest someone develops an inaccessible application that prevents someone else from doing a job, taking a course, etc.
Edit: I realize that was a rant. What rubbed me the wrong way about your comment was the suggestion that the problems with cross-platform toolkits are mainly cosmetic things or extra functionality that only spoiled Mac users care about.
Uh, i think you need to read again what i wrote as i explicitly write that there are more issues than just cosmetic things and accessibility is one of these - i just brought simple examples that anyone can test by themselves right now.
But also yes, not every program has to care about these, including accessibility. An image editor or a level editor for some game or some internal and/or throwaway tool that has a very explicit "audience" has no reason to bother about these.
Nah I agree accessibility is super important, and exactly the thing you'd want a UI framework to encapsulate. I don't necessarily think it's essential--people should be able to determine their target userbase themselves--but if you want to be a mainstream UI framework that competes with Electron, it's table stakes.
Comments
In reality, if you want to actually make a serious, usable and comfortable GUI, there is no cross-platform solution. There are many attempts, but none will let you create a GUI that actually fulfils all those requirements.
If you are making something serious, you will have to implement at least the GUI layer separately for all platforms.
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).
Neither of those are anywhere near good enough. "Looking reasonably native" is miles away from the goal.
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
They are obviously good enough for a ton of software
Why do I keep seeing people say this? People have been doing this for 30 years.
Fltk will let you do it in 700KB with no dependencies. (100KB if you're crafty). Juce, Qt, pyQt, opengl+imgui, opengl+nanogui all work well. There is also gtk, Tk, wxWindows ...
Where are you getting this idea from?
The idea isn't that you can't have some windows with text and buttons displayed with the same code on all platforms but that these windows, text and buttons wont look and behave like they are supposed to and expected by the users of each platform.
Now, outside of macOS this might not be much of a problem since Windows users were beaten into submission to accept any arbitrary look and behavior and Linux users never had a choice anyway.
I've never seen this actually be a problem other than people complaining about buttons looking different.
If you are worried about the shading on your buttons then you must have had all your problems solved already.
"People complaining about buttons looking different" is a problem.
But it isn't just "buttons looking different", it is also "buttons behaving different". As an example (that i often find annoying in programs with long lists), under Windows Qt scrollbars do not behave like native Windows scrollbars: shift click in Windows should cause the scrollbar to scroll at the point you clicked (like middle click on most X toolkits) but Qt ignores that.
Also it is "buttons not integrating properly". On macOS it is very common for example to have system-wide addons (services i think they are called) that add additional functionality to text fields, like "search with google", "text to speech", "show definition", etc. This doesn't work when a toolkit does its own text field controls. You can also see a similar thing on Windows: GTK+ applications (e.g. GIMP) ignore the emoji panel in their text fields that appear with Windows+; but native text fields work fine with it.
Now note that i'm not saying this is something that matters for all sorts of applications or is always a deal breaker (especially nowadays that, as i wrote above, most users outside of macOS have been conditioned to accept these), but it isn't something that you can handwave away as "having a different shade" either.
The more serious issue that nobody here has yet mentioned is lack of accessibility, e.g. for blind users with screen readers, in many toolkits. I say that is a deal-breaker if you're developing any kind of application that someone is going to use in their job, education, or other important tasks, unless the task is already inherently visual in nature. Qt has passable accessibility on Windows, Mac,and desktop Linux. GTK is accessible as part of GNOME. Electron, for all its faults, is as accessible as Chrome (pretty good these days). FLTK, FOX, Nuklear, TK, and a thousand other toolkits have zero accessibility. I've grown weary of bringing this up, and some of you may be tired of seeing it, but I feel compelled to do everything I can to make sure nobody overlooks this point, lest someone develops an inaccessible application that prevents someone else from doing a job, taking a course, etc.
Edit: I realize that was a rant. What rubbed me the wrong way about your comment was the suggestion that the problems with cross-platform toolkits are mainly cosmetic things or extra functionality that only spoiled Mac users care about.
Uh, i think you need to read again what i wrote as i explicitly write that there are more issues than just cosmetic things and accessibility is one of these - i just brought simple examples that anyone can test by themselves right now.
But also yes, not every program has to care about these, including accessibility. An image editor or a level editor for some game or some internal and/or throwaway tool that has a very explicit "audience" has no reason to bother about these.
Nah I agree accessibility is super important, and exactly the thing you'd want a UI framework to encapsulate. I don't necessarily think it's essential--people should be able to determine their target userbase themselves--but if you want to be a mainstream UI framework that competes with Electron, it's table stakes.
Smalltalk? Pixel-identical on all supported platforms AFAIK.
https://en.wikipedia.org/wiki/Smalltalk#External_links
Pixel-identical to itself and nothing else. That is useless.