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

341–350 of 577 posts

Re: Writing GUI apps for Windows is painful

#341

Post by jcelerier »

Wowfunhappy wrote: post #282
singpolyma3 wrote: post #209

Earlier quoted context omitted.

Not true at all. The LGPL does not specify anything about mode of linking or anything like that. What the LGPL requires is that the end user be able to take the source code for the LGPL part, modify it, recompile it, and then replace the functionality in your binary provided by that part with their new part. Obviously with dynamic linking this is almist trivial, the end user replaces the so or DLL and done. With norm…

> If you ship alongside your binary a bundle of eg .o files and a script that links them together with a .a for the LGPL part for example, this is also compliant without revealing the source code to your non-lgpl part. This is super clever, I love it! Does any software actually do this?

Yes. For instance some Cisco app on iOS that uses gstreamer (LGPL) does exactly this.

Re: Writing GUI apps for Windows is painful

#342

Post by daemin »

Like the author I too did an evaluation of various UI frameworks, though I ended up settling on WTL (Win32 with some ATL). I might switch away from it and make my own Win32 wrapper in time but for now it works well enough and writing custom controls that feel like standard controls is relatively easy. If you handle the drawing correctly it is also one of the fastest and snappiest systems around.

I had the exact same issues with WinUI3, where each time I compiled and wanted to run the application I had to install it into Windows, with its own start menu entry and registry entries and all that stuff. Really inconvenient and not worth it unless you like and desire that "new app" look of the Settings etc.

Qt wasn't too bad but you still had to do a similar install step within CMake to make the necessary Qt DLLs available to your application to run it. It's also not the fastest system around for UI.

Re: Writing GUI apps for Windows is painful

#343

Post by rfoo »

beagle3 wrote: post #334
rty32 wrote: 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…

> but 40MB. Oh man.

It is perfectly fine to build a 150KB or less executable today. But then OP decided they don't want to write paint functions for custom GUI and insist on finding a library to do so, I guess that's not what you did in 1999, right?

Re: Writing GUI apps for Windows is painful

#344

Post by adzm »

MikeTV wrote: post #205
ack_complete wrote: post #172

Earlier quoted context omitted.

> Most controls ask their parent what color they should be via a window message. There are a LARGE number of areas where this is not provided, such as the text color of a disabled control or the checkbox area of a checkbox control. Even for the cases where such customization points were provided, many of them were broken when theming was added in Windows XP and in comctl32.dll version 6 in Vista, which ignores some o…

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.

Check out my win32 dark mode menu bar in case it comes in handy.

Also I know far far too much about the internals of classic win32 rendering if you have questions

https://github.com/adzm/win32-custom-menubar-aero-theme

Re: Writing GUI apps for Windows is painful

#345

Post by [deleted] »

pjmlp wrote: post #214
glzone1 wrote: post #159

Earlier quoted context omitted.

WPF has been superseded (supposedly) by UWP / WinGUI / MAUI / Blazor?

Nope, the GUI story is so bad, that at BUILD 2024, WPF was made again an official Windows GUI framework for .NET devs, see BUILD 2024 sessions regarding Windows programming.

[deleted]

Re: Writing GUI apps for Windows is painful

#346

Post by oblio »

ranger_danger wrote: post #256
elpocko wrote: 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. ...

ImHex uses it for the entire UI

And that's a dev/debug tool, just as explained by OP.

Re: Writing GUI apps for Windows is painful

#347

Post by pjc50 »

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…

WinUI3 itself.

If you want to be "normal", or at least follow the Microsoft semi blessed path, and make an appx, that does not include WinUI3. The user installs it, and in the process pulls down WinUI3 (also an appx) if it is not already installed. It's only if you really insist on "self-contained" that this problem arises.

I say semi-blessed because of course Microsoft aren't really committed to WinUI3 and barely any of their own apps use it.

Re: Writing GUI apps for Windows is painful

#348

Post by gardaani »

glzone1 wrote: post #159
Const-me wrote: post #125

For requirements like that, I typically write WPF C# frontend, combined with C++ backend. Compared to ImGui, in WPF you’ll get a GUI designer, styling which allows easy dark mode, data bindings, data templates, animations, IDE support like live visual tree inspector, accessibility support, and more. If you use the legacy .NET 4 framework, the .NET runtime will come pre-installed on modern Windows. If you compile your…

WPF has been superseded (supposedly) by UWP / WinGUI / MAUI / Blazor?

WPF seems to be one of the preferred native UI platforms:

"Microsoft will refresh WPF with new Windows 11 theming and hyphen-based ligatures support for Microsoft .NET 9 and will continue to invest in WPF as one of the two preferred native user interface platforms on Windows."

The other preferred native UI platform seems to be WinUI 3: "WinUI 3 joins Windows Presentation Foundation (WPF) as the two recommended native UI platforms for developers."

https://news.microsoft.com/build-2024-book-of-news/

I don't know about MAUI / Blazor.

Re: Writing GUI apps for Windows is painful

#349

Post by boxed »

This was a big reason I switched to the mac many years ago. I was a win32 programmer professionally, but I was more productive on mac after a week or so of hobby fiddling around.

There is simply no contest. MacOS 10.0 was far superior as an environment to develop desktop apps when released, than Microsoft Windows is today with any toolkit you might want to choose.

Re: Writing GUI apps for Windows is painful

#350

Post by pjc50 »

markus_zhang wrote: post #52

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 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 anyone who wrote Windows GUI apps back in the late 80s -> early 90s before RAD is a thing.

The late 90s experience with VBA and the Visual Studio designer is, on the other hand, really good. As was the proprietary Borland Delphi experience.

You could do worse than try building an MFC app in VS to get something working and then reverse engineer the details out of that. Strings are not a pain provided you remember -DUNICODE and use wchar for everything (and the related functions).

Post reply on HN