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

251–260 of 577 posts

Re: Writing GUI apps for Windows is painful

#251

Post by smileybarry »

neonsunset wrote: post #238
smileybarry wrote: post #223

Earlier quoted context omitted.

WinUI3 is a can of worms that’s becoming palatable only with .NET 8 (and soon 9). In a normal configuration, you have to bring 500MB of dependencies with you, or ask the user to install a redistributable. You also need the user to install .NET 8, or bring said 0.5GB with you. WinUI3 can be used in unpackaged apps (I.e.: not appx) but has a few random caveats that just don’t work; random APIs that have a footnote of “…

What kind of build settings lead to 500 MiB binaries? I struggle to imagine something that could make the toolchain to emit such a large binary save for select degenerate cases of runaway generic specialization when you AOT compile an SDK that combines LINQ with 2102718201 enum types, all of which get their own set of generic instantiations for every internal iterator within LINQ - that's a known issue that is fixed…

It’s just because the WinUI3 libraries and/or .NET Core runtime take that much. Mostly WinUI3 IIRC.

And that’s when you use “selfcontained mode” rather than AOT publishing, now with AOT it’s considerably better.

Re: Writing GUI apps for Windows is painful

#252

Post by smileybarry »

alkonaut wrote: post #239
smileybarry wrote: post #224

Earlier quoted context omitted.

C++/CLI is managed code, it’s basically C++ compiled into .NET IL. If you’re writing C++ code running on .NET / .NET Framework, you’re basically writing masochistic C#.

But why even use C++ for the front end if it’s going to be .NET? Managed C++ is mostly useful as a shim, not as a platform language. It’s not really an alternative to C# on the .NET runtime but just some C++ extensions for interop with it. If you make a WPF/WinForms frontend then that should be the exe entry point, and that would likely be managed. Then your business logic would be the auxiliary DLL (which can be emb…

> But why even use C++ for the front end if it’s going to be .NET?

Because the author of the article wanted to use C++, I don’t know why. That’s why I called it “masochistic C#”.

Re: Writing GUI apps for Windows is painful

#253

Post by MikeTV »

ack_complete wrote: post #247
MikeTV wrote: post #205

Earlier quoted context omitted.

Do you happen to have links to any good documentation/articles on this topic? I'm working on what amounts to a dark theme for Win32 controls and largely making it up as I go along, relying on tidbits and off-hand mentions from defunct blogs.

Afraid not, had to piece together a lot of it myself. There are lots of examples available for various components of varying quality -- you'll find some code examples that don't work well with high DPI or all of the sub-modes of a control. Some controls like buttons, list boxes, list views are reasonably well behaved, especially when theming is turned off. Combo boxes and toolbars are more temperamental. Check boxes,…

Would you mind sending me an email (address in profile)? I'd love to pick your brain about some of the trickier ones I'm running into.

Re: Writing GUI apps for Windows is painful

#254

Post by neonsunset »

smileybarry wrote: post #251
neonsunset wrote: post #238

Earlier quoted context omitted.

What kind of build settings lead to 500 MiB binaries? I struggle to imagine something that could make the toolchain to emit such a large binary save for select degenerate cases of runaway generic specialization when you AOT compile an SDK that combines LINQ with 2102718201 enum types, all of which get their own set of generic instantiations for every internal iterator within LINQ - that's a known issue that is fixed…

It’s just because the WinUI3 libraries and/or .NET Core runtime take that much. Mostly WinUI3 IIRC. And that’s when you use “selfcontained mode” rather than AOT publishing, now with AOT it’s considerably better.

Self-contained/single-file mode is compatible with trimming and benefits from the work done to improve AOT story. As AOT binaries get smaller and ILLink's analysis gets smarter, the single-file trimmed binaries will see a part of such improvements.

The issue is that many GUI frameworks are not AOT-incompatible per se but rather trim-incompatible as they rely on reflection that is done in a way that is totally opaque to ILLink save for rooting everything.

You can try the following publish option anyway, and in many instances it "just works" (assuming .NET 8 SDK):

    dotnet publish -o out -p:PublishSingleFile=true -p:PublishTrimmed=true
Note: trimming was introduced in .NET 6, and NativeAOT was initially introduced in 7, so it had seen quite a bit of work to mature and improve by the time 8 shipped.

Re: Writing GUI apps for Windows is painful

#255

Post by WillAdams »

linguae wrote: post #69
nasretdinov wrote: post #32

Earlier quoted context omitted.

I think OpenStep actually had something like this in mind and had a Windows implementation too. It's apparently even used in Apple Windows apps like Safari, but of course it must not be complete enough to be able to fully replace native Windows API, and the incentive isn't there either.

There was an implementation of OpenStep for Windows named OpenStep Enterprise: https://forum.winworldpc.com/discussion/11422/openstep-for-w... It even survived Apple's purchase of NeXT, where the OpenStep API was renamed Yellow Box. There was a port of Yellow Box to Windows: https://www.betaarchive.com/forum/viewtopic.php?t=29049 In both OpenStep Enterprise and Yellow Box for Windows, while the UI elements still have…

The impetus here is that Adobe had initially promised a free, then low-cost license for Display PostScript --- when that was pulled, Apple had to come up with an alternative --- that and the fact that all the major app vendors announced that they weren't willing to do top--to-bottom re-writes using the NeXT frameworks (there was even a rumor that "Yellow Box" was named for the sake of Bill Gates' comment, "Develop for NeXTstep? I'll piss on it.")

So, Apple, led by Mike Paquette and many other talented folks from NeXT created Quartz (née Display PDF) and Carbon and instead of a consistent environment with a single API, we got an assemblage of technologies which had a Calculator app written in Java which took _forever_ to load, a Finder written in Carbon instead of Workplace.app, and icons cluttering the desktop and a Sidebar instead of a Shelf, and a bunch of Carbon apps.

Re: Writing GUI apps for Windows is painful

#256

Post by ranger_danger »

elpocko wrote: post #55
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…

Dear ImGui is for development/debug tools, not an UI for the end-user. It's great for small projects as long as you don't care about accessibility, or proper keyboard support, or adherence to standard UI conventions, or support for devices without GPUs, proper font rendering, etc. ...

ImHex uses it for the entire UI

Re: Writing GUI apps for Windows is painful

#257

Post by ranger_danger »

EasyMark wrote: post #228
deutschepost wrote: post #152

Earlier quoted context omitted.

Yes. But the article states that they don’t care about that. They just want a single executable.

I never understood the need for a single executable on windows when folders, zip files, and 100% free installers exist if you don’t like zip files. Also nearly all of the gui kits he’s shooting down have ways to build custom components if that’s what you want to do.

No need for an installer when it's just one file you can run anywhere. And folders/zips are way too hard for the average user. Ask me how I know. My partner gave up an entire game platform because it was delivered as a .7z file they could not figure out.

Re: Writing GUI apps for Windows is painful

#258

Post by ranger_danger »

markasoftware wrote: post #9

More accurately: + "portable" (single exe with no automatic unzipping of dlls or anything) + commercial and unwilling to redistribute compiled object files (which together with the "portable" requirement, means no LGPL) + dark mode Windows GUI apps is painful. Drop any one of these requirements and there are good established options. Specifically I think most "portable" applications use win32 because, usually, portab…

nuklear solves all of these for me, plus it's plain C

Re: Writing GUI apps for Windows is painful

#259

Post by bonestamp2 »

> Writing the GUI part of the program should not take more time than the actual functionality

I don't understand why this is a rule. I mean, I don't know what the author is trying to build, but in general the GUI is the part that the users spends all of their time interacting with. I don't see why it would be a problem if a little more time was spent there.

Re: Writing GUI apps for Windows is painful

#260

Post by bonestamp2 »

I work on several enterprise apps that are .NET but the GUI is a webcontainer with a web app. Unless there is something particularly high performance happening in the GUI, this works really well for several reasons:

1. We can update the gui without the user installing an update.

2. Lots of great web ui libraries, designers, and developers to make it look great.

3. Relatively lightweight

Post reply on HN