Writing GUI apps for Windows is painful • Hacker News Board

Re: Writing GUI apps for Windows is painful

#441

Post by shortrounddev2 » Mon, Jul 01, 2024, 2:27 PM UTC

akira2501 wrote: post #192

glzone1 wrote: post #153

Earlier quoted context omitted.

The lack of windows support for windows GUI's on windows is mind blowing. I remember absolutely whipping up Visual Basic line of business apps using the form designer in Visual Studio and data bound controls etc. If you wanted more there was MFC (with MTL developed by some insiders I guess at microsoft) The absolute insanity of going to WPF (wasn't data binding via reflection -> these apps got horribly sluggish!) the…

> The emphasis on Universal Windows Platform as "the future" of app development is absurd. Remember when Microsoft honestly thought they had a shot at making a mobile platform to compete with Android and Apple?

Say what you will about their chances of succeeding, but the Windows phone is the best phone I ever owned

Re: Writing GUI apps for Windows is painful

#442

Post by spintin » Mon, Jul 01, 2024, 2:29 PM UTC

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…

[dead]

Re: Writing GUI apps for Windows is painful

#443

Post by jerf » Mon, Jul 01, 2024, 2:30 PM UTC

When people ask "why isn't there an awesome native widget set for my favorite language?" I have often said that GUIs are way, way, way harder than you think. It's easy to create a toolkit for your exact use case, but to create a toolkit that fits everyone's use cases to some degree is vastly, vastly larger than merely creating a programming language and a reasonable standard library. Vastly.

This is a great example of why. A small set of reasonable requirements and already almost all the options on what is probably the best-endowed OS for toolkits are almost all disqualified, and what did fit was an odd solution that won't work for a lot of other use cases. It isn't that these are unreasonable requests per se, it is that this is how this space works. Everybody has weird requirements of some sort, pretty much all the time, and getting even reasonable coverage is a huge, huge project.

Re: Writing GUI apps for Windows is painful

#444

Post by alok-g » Mon, Jul 01, 2024, 2:33 PM UTC

Liquid_Fire wrote: post #438

alok-g wrote: post #413

Earlier quoted context omitted.

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

Qt is also available under the LGPL. There is no license advantage to using CopperSpice. I'm not sure what GP is referring to.

Some parts of Qt are GPL only.

Re: Writing GUI apps for Windows is painful

#445

Post by shortrounddev2 » Mon, Jul 01, 2024, 2:37 PM UTC

Dwedit wrote: post #142

beart wrote: post #27

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…

Windows Forms (C#) is basically a continuation of Visual Basic, it's not very painful at all. The only painful bits are when you need to lock a bitmap and deal with raw pointers, and you need to use the "unsafe" keyword.

To me, Windows Forms is where MS should have stayed. I don't want XAML to compile to C# code, and I don't want to be forced into using their MVVM system. I just want to be able to put boxes on the screen and fill them with text, then handle user interactions with callbacks. Basically, vanilla javascript but in C#

Re: Writing GUI apps for Windows is painful

#446

Post by neonsunset » Mon, Jul 01, 2024, 2:42 PM UTC

pjc50 wrote: post #437

neonsunset wrote: post #369

Earlier quoted context omitted.

Not limited to CLI (even at release in .NET 7 it was possible to use it with ASP.NET Core with limitations and there were custom templates to make it work with some GUI framework I think, and MonoGame already worked partially), certainly not in .NET 8. I’m not sure about WinUI 3 itself, but a lot of things today are AOT compatible. And naturally single-file + trimmed works almost everywhere, in some situations requir…

"Single file" has the annoying property that it unpacks all your assemblies at runtime and dumps them in a temporary directory. There's no good reason it couldn't byte-load them directly out of the executable instead.

Do you mean IncludeNativeLibrariesForSelfExtract attribute? This is a related but still separate feature. If you mean the managed assembles, then it works differently:

"Only managed DLLs are bundled with the app into a single executable. When the app starts, the managed DLLs are extracted and loaded in memory, avoiding the extraction to a folder. With this approach, the managed binaries are embedded in the single file bundle, but the native binaries of the core runtime itself are separate files."

https://learn.microsoft.com/en-us/dotnet/core/deploying/sing...

For """embedding""" native dependencies into the binary without self-extract, you can't really do that, the closest alternative is statically linking them into AOT compilation instead (but that gets tricky with large dependencies).

Re: Writing GUI apps for Windows is painful

#447

Post by bux93 » Mon, Jul 01, 2024, 2:42 PM UTC

throwaway2037 wrote: post #293

Reading many of these comments makes me realise that the whole premise is flawed. I "vote" to rename this blog post as: > Writing GUI apps for Windows is painful when requirements are unrealistic They should try to target .NET Framework 3.5 using WinForms. That is my best suggestion, as all recent versions of Windows will have this installed (at least).

The requirements are not just unrealistic, but, you know, wrong?

> It is extremely hard to stylize native Win32 controls.

Yes, it should be! I know Microsoft is errant in its ways itself, but controls should not be custom, they should be standard.

Re: Writing GUI apps for Windows is painful

#448

Post by daemin » Mon, Jul 01, 2024, 2:42 PM UTC

ClumsyPilot wrote: post #415

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…

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.

Are you saying without an installer, or unpackaged as in without a package identity ala https://learn.microsoft.com/en-us/windows/apps/get-started/i... ?

Re: Writing GUI apps for Windows is painful

#449

Post by cageface » Mon, Jul 01, 2024, 2:43 PM UTC

bobajeff wrote: post #436

cageface wrote: post #272

Earlier quoted context omitted.

My experience with SwiftUI on the Mac is that it still needs a lot of work. Documentation is poor. Performance can be bad if you do things in a straightforward way. Supporting older versions of the OS is quite painful etc.

Documentation remains the number one reason I personally don't make Android apps and why electron/web apps are the way to go for most GUI apps these days.

Unfortunately it doesn’t seem like having good, bug free, modern and well documented desktop APIs is a priority for anyone anymore.

Re: Writing GUI apps for Windows is painful

#450

Post by openrisk » Mon, Jul 01, 2024, 2:46 PM UTC

shortrounddev2 wrote: post #439

openrisk wrote: post #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 w…

There is a UI framework which is fast, functional, cheap, and (depending on your personality) pleasant: the web browser. HTML and CSS are go-to strategies not just because the web is the target platform for probably most if not almost all user interfacing software these days, but because HTML and CSS are very forgiving. Native UI frameworks are written by software engineers who demand type safety and XAML-like featur…

There is certainly a strong case for the web platform as an all-weather gui platform but on actual mobile and desktops of here and now it is not a no-brainer choice. Its document oriented nature fits some use cases better than others. Not to mention that with the near exclusive focus on (incompatible) javascript frameworks it is not exactly clear even what "html" means...