Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Writing GUI apps for Windows is painful

tulach.cc

Post reply on HN
Print view View original

161–170 of 577 posts

Re: Writing GUI apps for Windows is painful

#161

Post by barrkel »

eschaton wrote: post #88
Aurornis wrote: post #19

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…

If instead of insisting on custom UI styling the author just used the system UI, they could probably build a pretty straightforward Windows application. It’s the scourge of “brand identity” that has people thinking graphical applications are hard. 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 ei…

This indeed. Custom UI widgets for Windows apps are really not necessary most of the time, and fitting in with the system theme is all you ought to aim for, most of the time.

There are exceptions, for very rich dense UI, for UIs that need to be cross-platform, but if you're writing a Windows app, it should look and feel like a Windows app.

Re: Writing GUI apps for Windows is painful

#162

Post by mike_hearn »

chipdart wrote: post #48
alkonaut wrote: post #40

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…

> 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. What I find the most mind-numbing thing about the blog post is the way WinUI3 was excluded. WinUI3 looks like an exac…

Some of the issue is he has outdated understanding of AppX packages (MSIX). You can use all of Win32 from an MSIX package, and all of WinRT, and WinUI3 etc. It's actually the other way around: there are some Win32 APIs that only work if your app is packaged.

Re: Writing GUI apps for Windows is painful

#163

Post by mike_hearn »

withinrafael wrote: post #158
fassssst wrote: post #145

Just use WinUI 3. Opting into MSIX packaging no longer requires an App Container sandbox. More info here: https://learn.microsoft.com/en-us/windows/msix/desktop/deskt... Full disclosure: I work at Microsoft.

runFullTrust apps are still subject to file system and registry redirection as well as various capability checks. Running fully unencumbered requires restricted capabilities that only Microsoft can approve.

You can opt out of those with manifest metadata. Capabilities aren't enforced if you distribute out of the app store.

Re: Writing GUI apps for Windows is painful

#164

Post by torstenvl »

linguae wrote: post #87
criddell wrote: post #49

Earlier quoted context omitted.

> 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.

I wonder how possible it is to design a cross-platform GUI framework that not only uses the native UI widgets of each underlying platform, but also respects each platform's human interface guidelines. I'd imagine this would be very hard work, especially the part about respecting each platform's HIG, but the increased power of AI tools could potentially make this task easier. Such a framework could potentially be an a…

wxWidgets does this pretty well, e.g., wxSingleChoiceDialog has "OK" "Cancel" on Windows but "Cancel" "OK" on Linux/GTK.

Re: Writing GUI apps for Windows is painful

#165

Post by jenscow »

withinrafael wrote: post #158
fassssst wrote: post #145

Just use WinUI 3. Opting into MSIX packaging no longer requires an App Container sandbox. More info here: https://learn.microsoft.com/en-us/windows/msix/desktop/deskt... Full disclosure: I work at Microsoft.

runFullTrust apps are still subject to file system and registry redirection as well as various capability checks. Running fully unencumbered requires restricted capabilities that only Microsoft can approve.

you can turn some of that crap off: https://learn.microsoft.com/en-us/uwp/schemas/appxpackage/ua...

Re: Writing GUI apps for Windows is painful

#166

Post by mike_hearn »

fleabitdev wrote: post #108

Unlike Windows, Apple and Android have managed to publish modern UI libraries for their own platforms - but in both cases, this involved migrating the whole platform to a new programming language (Swift and Kotlin, respectively). If I remember right, C# also has a few features which were only added to make Windows Forms and WPF more ergonomic. I'm starting to suspect that general-purpose languages just aren't flexibl…

The issue is the React paradigm, which is a bit questionable to begin with. It's a sort of fake OOP in a trenchcoat pretending to be something else, whilst abusing the language in ways that requires compiler plugins. My experiences with Compose and SwiftUI have been ... not that great. I kinda wish people would just have kept investing in their OOP toolkits.

Re: Writing GUI apps for Windows is painful

#167

Post by achr2 »

neonsunset wrote: post #86

The author would have been served extremely well by AvaloniaUI with NativeAOT target if they were willing to drop their assumptions regarding C# that are no longer true. (I wonder how well Uno Platform fares in comparison? It targets native controls first and foremost but is supposedly NativeAOT compatible too)

A second recommendation for Avalonia. It deserves the acclaim.

Re: Writing GUI apps for Windows is painful

#168

Post by CyberDildonics »

criddell wrote: post #43
CyberDildonics wrote: post #11

Earlier quoted context omitted.

Anyone can compile a static binary with FLTK and have the binary size start under 100KB.

You can do that with straight win32 as well. Steve Gibson has a bunch of utilities and most of them are pretty tiny. His DNS Benchmark is one of the larger utilities at 169k.

I like win32 and you can get a lot smaller with win32, but there are a lot of things missing. FLTK has a lot of components, component layouts, fonts, file system stuff, networking, audio, an openGL context, image loading and it's cross platform.

Re: Writing GUI apps for Windows is painful

#170

Post by cjk2 »

chipdart wrote: post #75
cjk2 wrote: post #13

The painful bit is C++. I did a fair bit of that going back to MFC. Knocking stuff out in C# with WPF and WinForms was quite nice in comparison. I haven’t found anything nicer.

> The painful bit is C++. I did a fair bit of that going back to MFC. I'm sorry but referring to MFC while referring C++ is a telltale sign you don't really have any meaningful experience in the field. Developing GUI apps for Windows is a breeze with frameworks like Qt. You only suffer if you're a masochist, but the rest of us prefer to pick things that make sense.

I have a lot of experience, in the real world, which is somewhat less ideal than "just use Qt - it's a breeze".

How do you manage a 15 million LOC desktop app originating from the late 90s which contains chunks of win32 native, ATL, MFC, custom GDI+ wrappers all sorts?

Aye you fuck off and work somewhere else that's what you do. Which is why it's still written in win32 native, ATL, MFC, custom GDI+ wrappers.

They paid two companies to come in and rewrite it, first in Qt which was a complete failure. Then in Electron etc, which was also a failure.

Post reply on HN