Live data from Hacker News

Writing GUI apps for Windows is painful

tulach.cc

131–140 of 577 posts

Re: Writing GUI apps for Windows is painful

#131

Earlier quoted context omitted.

As a non-Windows user, I'm confused, maybe you can clarify: > If you use the regular Win32 controls then they will automatically get the styling the user has set. Does that mean they'll get dark mode if the system is in dark mode? In which case I don't understand what the author is complaining about. Sounds like dark mode would be working as intended. They want "easy styling" but I took that to mean things like icons…

They'll get dark, light, rainbow, whatever the user has set. This was a feature since at least Windows 3: https://news.ycombinator.com/item?id=25871787

I don't think this actually reflects the new light/dark mode people are referring to here. It will most likely always be the default theme - light.

Also changing those old themes has a good chance to "break" any (poorly made) apps doing their own themes. You could change some colors in the palette and parts of the UI could end up being difficult or impossible to read. Happens if the app uses a combination of palette controlled colors and custom colors.

Re: Writing GUI apps for Windows is painful

#133

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…

I'm amazed Fury3 worked under WinG. I used WinG for some simple 2D games, but I don't think I would have tried texture-mapped 3D!

We wrote this game on DirectX 1.0. It was a pig because the game was designed to be all 2D sprites, but early in the project it became clear there wasn't enough RAM, so I wrote a 3D engine that integrated with the 2D backgrounds. The video cards of the day didn't like that shit, and there was no acceleration at the time.

https://www.youtube.com/watch?v=9UOYps_3eM0

All the DirectX code itself felt sluggish as games were coming from highly optimized bare-metal C/x86 to running on a multi-tasking OS through an API that was written in (probably) pretty unoptimized C++.

Re: Writing GUI apps for Windows is painful

#136

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…

At least you can hex-edit or resource-edit the Alt+Letter back into a standard windows button or menu that's missing an accelerator key. Just add the missing &.

Re: Writing GUI apps for Windows is painful

#137

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…

Life was good with Windows 2000, GTK2 and MacOS9, styling was clear and had purpose. GTK and MacOS even had extensive Human Interface Guide documentation.

Re: Writing GUI apps for Windows is painful

#138

Earlier quoted context omitted.

Sciter desperately needs an evangelist who can reply and help people with their problems and just in general provide support and work on the ecosystem. I think from what I remember from indiehackers you are not there yet to be able to afford it but we desperately need that. Even paying pravic to keep the libraries for different languages up to date would be of great help.

Sciter's support forum is pretty active : https://sciter.com/forums/ Mr. Yuri (Pravic) has his own agenda these days. As far as I know creation of Go, Rust and Python backends for Sciter was a method for him to determine best frontend technology for his organization. If someone wants to take care about Go, Rust and Python wrappers - let me know.

Ultimately as a user / customer I dont care who maintains the bindings I need to use to achieve my goal.

Re: Writing GUI apps for Windows is painful

#139

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…

The problem with this hands off approach is that Microsoft has not updated its base controls and does not provide some capabilities out of the box. It instead only offers modern controls via its Win UI 3 framework, which is squarely designed for C#.

Re: Writing GUI apps for Windows is painful

#140

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…

> Windows GUI apps is painful. Drop any one of these requirements and there are good established options. The "portable" one is not a hard requirement. It's a whimsical self-imposed constraint, which makes as much sense as complaining that you can't stand on your right foot on Tuesdays. All installer toolkits released in over two decades support deploying arbitrary components. Is this not a solved problem? WinUI3 sup…

Well I remember one project where having the app small and portable or at least self-contained was a hard requirement. It involved an embedded device (ridiculously complex and over-engineered embedded device) that used customized USB flash sticks for user authentication, data transfer and firmware updates and configuration. The partitioning scheme of the update/configuration scheme meant that I had only about 16MB of free space on the windows-visible partition for a Windows GUI configuration application for the thing.

Originally I started writing it in MFC, but MFC is not exactly good match for something so trivial and all the abstractions meant for document-based applications were mostly in the way and I ended up doing it in Lazarus.

Post reply on HN