81–90 of 577 posts
I'm working on a GUI toolkit that should match the requirements: Slint - https://slint.dev Can be compiled statically in a single .exe that is smaller than 40M. Has a license that allow proprietary on desktop for free. Has dark/light styles. Even comes with a (work in progress) drag and drop WYSISYG editor.
[flagged]
Writing GUI apps for Windows in C++ is painful There, fixed it for ya. There are solutions if you're not hell-bent on using C++, be it .Net, Lazarus (FreePascal) or Delphi. We're using Delphi at work and for the most part it's super simple and easy.
> Writing GUI apps for Windows in C++ is painful I don't think so. Qt makes this a trivial problem, and WinUI3 supports C++ as a first class citizen. I'd argue that desktop development for Windows was never as good as it is right now.
But fair enough, it's quite good. If I had to write a C++ UI application, it'd be on my shortlist.
Writing GUI apps for Windows in C++ is painful There, fixed it for ya. There are solutions if you're not hell-bent on using C++, be it .Net, Lazarus (FreePascal) or Delphi. We're using Delphi at work and for the most part it's super simple and easy.
> Writing GUI apps for Windows in C++ is painful I don't think so. Qt makes this a trivial problem, and WinUI3 supports C++ as a first class citizen. I'd argue that desktop development for Windows was never as good as it is right now.
That's not a problem, it's a feature. I am absolutely bloody sick of apps that go out of their way to reinvent the standard UI controls in perplexing ways and behave unexpectedly. Following the system UI preferences is what you should do, and it irritates your users if you don't.
There is a “hidden” dark mode for Win32 controls used by Windows File Explorer that you can activate, but it covers only some of the controls and still doesn’t look good.
Don't do that. If you use the regular Win32 controls then they will automatically get the styling the user has set.
I've been writing Win32 apps for close to 30 years now. It's sad to see the regression in UIs over the years.
Windows (MS) and OSX (Apple) need to agree on a GUI interoperability API. Either hammer something out, or adopt one/more of the OSS GUI framework specifications from QT and GTK. It MUST be open spec. It MUST be free for all/any to implement. It MUST either be included or be in the primary vendor (MS, Apple, distro) software center. A simple Hello World, click OK to exit the program application should be able to be cr…
> need to agree on a GUI interoperability I hope they don’t. I like that the different platforms I use feel and look different. In fact, I wish there was more variety. I wish there were still Atari, and Amiga, and BeOS, Tandy, and all the other interesting platforms competing for users with different ideas of how computers should work.
This is a good overview of some of the options, but the author’s specific requirements push it in a specific direction that eliminates a lot of options. Specifically, the requirement for completely custom GUI styling without writing his own render functions means it’s really a task of selecting easy, customizable GUI libraries rather than generic GUI work. The requirements to be self-contained executables and under a…
Same on the Mac: If you want to build a Mac application, your best bet will be AppKit or SwiftUI and using system controls. And when the OS updates your application will either update with it, or need only minor tweaks and a rebuild to look good.
Writing GUI apps is painful everywhere, and has been for years. I remember the half-baked transition from Windows Forms to WPF, which was then taken-over by the Windows Phone initiative, which was also extremely painful and half-baked. There's a reason electron is so popular, despite all the complaints about it as a platform. Don't blame the electron devs, blame Microsoft for completely failing to support their own p…
Disagree. GUI development on Apple platforms using either UIKit or Appkit is something I've always found expressive, simple, and fun. SwiftUI is a different beast, but to say it's painful everywhere is not accurate.
While it’s a bit cumbersome, he doesn’t really point out any major flaw with the WinForms/WPF ideas, other than of course requiring two stacks. He says he wants native code and wouldn’t want any C# visible but doesn’t explain why. Fear of reverse engineering? UI code rarely contains anything secret. Also the single exe deployment, while convenient at times, is perhaps not worth the hassle in this scenario. Using a pa…
Agreed. I had the exact same question. From the article: "The issue is that with bundling the .dll, it would still mean it being extracted somewhere and writing additional code for the P/Invoke to work, and C++/CLI gets compiled to .NET IL code, in other words, you can open the resulting app in dnSpy and see the C++ code translated to C# equivalent (which is not what I want, I want native code)." I don't understand w…
I don't think the author is talking about interop here, but rather the fact that GUI front-end code written in C++/CLI still ends up being managed rather than compiled to native code. I suppose the author insists on the front-end executable being nothing but a PE x86-64 binary without any runtime/GC embedded in it, pure native code.