Live data from Hacker News

Writing GUI apps for Windows is painful

tulach.cc

411–420 of 577 posts

Re: Writing GUI apps for Windows is painful

#411
post #278

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…

Agree. "Single executable" combined with "less than 40mb" is just looking for trouble for what the author is trying to do. If you want to do win32, go ahead and give up styling. Otherwise, make compromises. I think many of these are excellent choices chosen by many programs that I use, it's the author's stringent requirements and unrealistic expectations that is holding back.

My app is around 500 KB (not megabytes) and it supports dark mode (see https://www.abareplace.com/). So this is definitely possible without using Electron or bloated GUI libraries.

Re: Writing GUI apps for Windows is painful

#412
post #393

Earlier quoted context omitted.

I have little sympathy for that kind of argument, imagine a carpenter complaining that they have to buy wood and nails. Besides, a Qt license for small businesses is nowhere near thousands of dollars. Only in software development do we expect quality tools to be given to us free of charge with no strings attached.

Qt for Application Development Professional (ADP) is 3460 €/Year. If you're making something which you sell for $50 or so you'd need 100 sales per year to just pay for the development environment. That also assumes that it took you less than a year to make said product.

'Qt for Application Development Enterprise - Small Business (ADE-SB)' is $499.

Re: Writing GUI apps for Windows is painful

#413
post #66

Earlier quoted context omitted.

Isn't the issue with Qt exactly what the GPL intended? In that case, any Qt fork would force him to also comply with the GPL, and supply the source code of his project.

CopperSpice is LGPL, not GPL. It's not a problem.

Hmm. How could that be when it's based on Qt?

Re: Writing GUI apps for Windows is painful

#414
post #393

Earlier quoted context omitted.

Qt for Application Development Professional (ADP) is 3460 €/Year. If you're making something which you sell for $50 or so you'd need 100 sales per year to just pay for the development environment. That also assumes that it took you less than a year to make said product.

'Qt for Application Development Enterprise - Small Business (ADE-SB)' is $499.

You're right. I didn't see the Small Business tab when I was quickly looking through it.

Still ends up being a blocker when you're not sure how many copies of the product you'll sell.

Re: Writing GUI apps for Windows is painful

#415

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…

Agreed, this is a bit like writing ‘developing iPhone app is painful’ but not using anny officially supported tooling.

fact that you must ship the app Unpackaged is particularly strange.

Re: Writing GUI apps for Windows is painful

#416

Earlier quoted context omitted.

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

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 “…

I don't understand why Microsoft puts it on the user/dev to make sure their own dependencies and "VC redistributables" are installed.

Like shouldn't Windows 11 just either have that already or pull it down as needed as it's an official MS library.

Feel I always hit a roadblock when setting up a new PC where one of the things needs that but the dev didn't provide it and I have to get it myself. Which feels weird when it's an official MS thing from their official dev tools.

Re: Writing GUI apps for Windows is painful

#417
post #278

Earlier quoted context omitted.

Agree. "Single executable" combined with "less than 40mb" is just looking for trouble for what the author is trying to do. If you want to do win32, go ahead and give up styling. Otherwise, make compromises. I think many of these are excellent choices chosen by many programs that I use, it's the author's stringent requirements and unrealistic expectations that is holding back.

This comment makes me feel like I live on a different planet. In 1999, I built a completely custom Win32 GUI for a (brandable) chat application - that was the product the company I worked for was selling. Pure C and C++. It was a 32-bit app, not 64 bits. And we felt bad for it being 250KB single executable (skin included in resource section) and not “150KB or less” as was our initial target. But making it accessible…

> In 1999, I built a completely custom Win32 GUI for a (brandable) chat application

Given that it’s windows, it might still run today, so it likely is still possible

Re: Writing GUI apps for Windows is painful

#418

I'm teaching myself the Win32 API for a future RE project, thinking that knowing it helps with the reverse engineering effort. I have just achieved creating a window, loading a text file and printing it on the main window. Scrollbars are there but don't work yet. It actually take s a lot of work. The boilerplate code is OK but I never realized that showing strings on Windows is such a PIA. I have deep respect for any…

Check out the Scrollbars series from Raymond Chen:

https://devblogs.microsoft.com/oldnewthing/20030731-00/?p=43...

https://github.com/mity/old-new-win32api?tab=readme-ov-file#...

Re: Writing GUI apps for Windows is painful

#419
post #404

Earlier quoted context omitted.

If you really want native look and feel then really your only choice is to use the native toolkits. I'm not convinced many users care that much about this though. They spend most of their day using apps that don't use native controls and I think they're all pretty used to it by now. I prototyped a bunch of different desktop toolkits and I think that today Flutter is by far the most polished and mature. I've had overa…

Thanks, I will have a look at that. Serendipitously, I'm in the market for a new music player! Yeah the Google risk... seems like they came out strong in support of Flutter at their last dev conference, but at the same time it does _not_ look like they're using it for their main apps.

Please let me know if you have any feedback or suggestions for the player.

And yes I’d feel more confident in Flutter if Google was dogfooding it a lot more.

Re: Writing GUI apps for Windows is painful

#420
One would think that after three decades of the windows metaphor and billions of man-hours writing such applications, writing GUI apps (for any platform) would be a much more pleasant experience?

One could imagine a framework that would absorb all this historical know-how and turn GUI app development into a zero marginal cost exercise (fast, functional, cheap and maybe even pleasant) but who would push for this and why?

Maybe its a case of somebody not learning a lesson when their economic interest depends on not learning it?The overview of existing frameworks (including browser/webview based) suggests there is a sort of stagnating stalemate that feels sub-par but probably works just fine for those who have any leverage over the status-quo.

Post reply on HN