The question still remains then of which to use for each platform.
On macOS there is Cocoa (Swift or ObjC(++) or pure CPP) and Swift UI.
On Windows there is .NET C# or CPP and a bunch of other stuff.
Any thoughts?
The question still remains then of which to use for each platform.
On macOS there is Cocoa (Swift or ObjC(++) or pure CPP) and Swift UI.
On Windows there is .NET C# or CPP and a bunch of other stuff.
Any thoughts?
He also has guest posts sometimes about/by other successful desktop software product creators. One of them was about Beyond Compare, a GUI file comparison tool, written in Delphi, IIRC.
I have read many of his blog posts, and they are quite interesting and informative.
For Windows, Microsoft has a history of releasing a new UI technology and then deprecating it. Their latest toolkit is WinUI 3. Given Microsofts dedication to backwards compatibility I think you could pick any of their toolkits, even the WinAPI. I should mention that WinUI 3 is an oddball because Microsoft is not shipping it with the OS, but rather vendors (you) must ship the toolkit with your app.
For Linux, the two most popular UI toolkits are GTK and Qt. But in truth Linux is just a kernel and it is the distro that decides what toolkit is "native". Maybe consider which distro(s) you'll target rather than treating Linux as a monolith.
For Windows, I think it goes the other way. Microsoft is always coming around with a new UI model that's half-ass and will be dead next year. Use the old ways: MFC will never die.
Microsoft can't seem to make up their mind on what UI platform people should be using. It's a mess. But they generally do support old platform, unlike Apple. I gag at thought of writing MFC code in 2024. But each to their own.
In any year. Could never grok it, when it was newish, what with its crazy opaque AFX macros, although I could somewhat easily understand Win 32 C programming (Petzold book etc.), even though that was lower level, and I was new to event-driven GUI programming then.
I think it's crazy that it's closed source too. It's a big black box which makes debugging hard. Plus its the kind of framework that does a lot of magic stuff where you scratch your head wondering what is going on.
SwiftUI is insanely productive when it comes to building mostly simple list and form applications.
I highly recommend that you try it, you can always build a component or large sections using UIKit if you run into issues.
At Ditto almost all of our enterprise customers use SwiftUI over UIKit because SwiftUI is so productive for the vast majority of use cases. Does it have parity with UIKit? No… but it’s never been a dealbreaker for us.
Qt is to PyQt and PySide as wxWidgets is to wxPython, roughly.
Check FLTK (Fast Light Tool Kit) too (C++).