Live data from Hacker News

Writing GUI apps for Windows is painful

tulach.cc

451–460 of 577 posts

Re: Writing GUI apps for Windows is painful

#451

> uses native Win32 components and offers no styling options It's a feature. Custom styling should be considered a hostile pattern in most cases, except in highly specialized software with workflows dependent on prior user experience, such as DAWs.

> Custom styling should be considered a hostile pattern in most cases Why? Almost every website has custom styling and yet it doesn't seem to inhibit users from using them. Good UI/UX patterns seems to be universal. As consistency is part of good UI/UX there are things that should be consistent with the underlying platform. But consistency with the platform is not equally important for all things. For some things, li…

How would you know inconsistency among websites isn't inhibiting users from using them? There's not a Web A and Web B to do A/B testing on.

Roundness of buttons? Buttons shouldn't be round in the first place. Back in the day, they were these rectangular things with a shadow and a highlight. You could instantly things you can and cannot click on. Now, it's anyone's guess. Do people click on the wrong stuff? Do people fail to discover functionality because it's hidden in plain sight? Of course they do!

Is there a place for custom components, yes, but not to the extent that every website out there is styling their buttons, and that even Windows itself is hiding scroll bars.

Re: Writing GUI apps for Windows is painful

#452

Earlier quoted context omitted.

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

It seems to have become the no-brainer choice. Lots of mobile apps just load html views, and probably most desktop apps I see these days are just electron apps. You can reason about the best use case for HTML vs XAML vs Swift, but it seems that the speed of development time and the insane amount of community support out there has made the web the clear winner

Re: Writing GUI apps for Windows is painful

#453
post #305

Earlier quoted context omitted.

Your profile doesn't list your email, so I'm posting here... is this the paper you were looking for? https://depts.washington.edu/acelab/proj/dollar/index.html Your original post for context: https://news.ycombinator.com/item?id=26152600

It was!! That’s absolutely amazing, what a surprise after all these years :) Many thanks for hunting me down in some comments!

Awesome, I'm so happy to hear that!

Re: Writing GUI apps for Windows is painful

#455
WPF is still a perfectly viable solution

> 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 how that makes WPF a non-viable solution. The author seems to have pretty strong feeling that it should absolutely be native code, but it’s not clear why

Re: Writing GUI apps for Windows is painful

#456
post #55

Earlier quoted context omitted.

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

imgui offers incredible development speed. And I've used it many times with great success. It's unorthodox yes (and there's a long-open bug I won't talk about again) but it's dear to my heart. It's like MFC on steroids: You don't have to leave C++. But yeah at least a few of those caveats remain. Although keyboard navigation and font rendering have quite a bit of support.

Due to what reasons does imgui offer incredible development speed?

Re: Writing GUI apps for Windows is painful

#457

Problem: It is extremely hard to stylize native Win32 controls. 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 Explo…

Never coded a GUI app but speaking of regressions: As a heavy windows KB user, losing the ability to alt+letter all the things to /quickly/ navigate windows apps is incredibly frustrating. I've read that Mac OS envy infiltrated the WinUI time and while some may prefer the aesthetics, on Windows 11 apps like mspaint I can no longer navigate anywhere near as quickly. From milliseconds to multiple seconds. I'm incensed…

I'm confused by your alt key navigation in paint. I just opened paint and it still supports alt+key to do things in Paint.

Re: Writing GUI apps for Windows is painful

#458

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…

I've gone through the same process of evaluating x-platform alternatives and I can now understand why Electron is so popular.

I mean, you do have the unreasonable bundle size, but other than that you can make really good looking applications using the same tools you can use to make web sites for both desktop and mobile.

Re: Writing GUI apps for Windows is painful

#459

A. If a gun were placed to your head and you had to write a native Windows app, what stack would you use? B. And, if you had to write a cross platform app, which framework would you use?

I presume we are talking about GUI programs:

A. Delphi --- easy choice (or C++ Builder if I had to use C++) B. Also Delphi --- it supports macOS (arm64 + x64), Linux, and Windows

If I have to write a CLI app, I'm probably picking Go or Rust.

Re: Writing GUI apps for Windows is painful

#460

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…

He should have used C++Builder. Native Windows widgets (so you get, eg, IME support) but it can theme them. And comes with dark themes!

Edit: and fully static linking. Might be a meg or so.

Post reply on HN