Writing GUI apps for Windows is painful

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 either update with it, or need only minor tweaks and a rebuild to look good.

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.

The blogger sounds like they put up a bunch of arbitrary constraints that in normal circumstances wouldn't even be issues.

In the process it's those arbitrary whimsical choices that reject the very obvious choices along with any happy path.

For example, it's baffling that there are already a few FLOSS forks of Qt out there, but the blogger failed to cover them. If the author likes Qt so much, those would supposedly be the obvious choices. But no.

Once again, you are left out of options if you go out of your way to avoid each and any option.

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

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.

If you’re on windows and want a “standard” guy, either use the .net GUI or Qt , if you want completely custom and willing to do the work use QML or ImGui (or variant like eGUI)

Yeah, I can confirm that writing windows GUI apps is not at all painful for me. I still use Windows Forms in .NET 4.8 and my executables are < 1mb, Visual Studio's form designer is very easy to use, you can subclass all the .NET UI controls and customize them however you want. There's always been accessibility and even support for high DPI.

40MB seems like a weird requirement. If it’s under 1GB, I don’t think most people really care any more about executable size. Memory usage is still relevant, but 1GB is going to be less than 1% of disk usage for almost everyone.

he didn't want to pay for a license

Well that's the killer right there. I too think it's way too painful to write Windows UI, especially if you want to stay away from Electron (which you should in almost all cases), but refusing to pay money for good software is going to severely hamper your goals in 99% of cases.

Title is "Writing GUI apps for windows is painful", and then the author slaps on a bunch of bullshit constraints but pretends to be covering the general case. Sorry dude, if you want to do that then change the title to something appropriate like "Writing small, custom styled GUI apps for windows is painful". Otherwise this is bait and switch.

Implicit (for me anyway) in the title is that you are talking about vanilla GUI apps. Writing vanilla Windows GUI Apps is trivial and there are a bunch of tools that handle this extremely well. The article covers many of them but chooses to disqualify them for reasons.

Then we have ImGui as the tool of choice, but now this is qualified as only for "simple apps". Really? After all the fuss about constraints not being met? A bit of cognitive dissonance here I think.

More complex functionality things can get difficult but often even these are handled depending on the tools.

For vanilla dev the clear winner in terms of productivity has to be WinForms. Or if you can live with the clunky IDE - Lazarus. (You're allowed to replace with your own favorites.)

The real challenge is not writing GUI apps for windows, but rather is in writing cross platform apps.

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.

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.

Qt makes such amazing apps. I love KDE and the apps they spawned like Kate, KDEnlive, Krita.. It's no wonder their apps are so popular on Linux and windows alike. Unlike GTK apps even though it does have bindings for Windows.

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 this change personally, and I feel totally confused by it from the perspective of MS. In the era of AI and automation, slower screen draw times will make a significant impact to performance and energy use. I hope someone like Mark Russinovich, Kevin Scott, or Satya Nadella will notice and change course.

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, some colors, etc. Not totally replacing what buttons look like. I agree -- being consistent with the OS is a good thing.

That's not a problem, it's a feature.

1000 times this. I want software I'm running to look like the rest of the OS (and every other application) and respect my OS-level UI preferences.

In the case of Win32 using the OS primitive controls mean that your application gets tons of accessibility and preference features "for free" (albeit Microsoft has done a good job in later Windows releases of removing the functionality to set some of these preferences).

There is no value add in making your app UI look bespoke. All the labor you're putting into that work is labor that could be better spent on functionality, features, and optimization. When I see an overly "precious" UI on Windows (owner-drawn controls, animations, fades, etc) I immediately question the ability of the developer to prioritize.

As a mobile dev, it should be the same for mobile apps?

If you are on iOS, you could just use what Apple gives you with very little customizations. The app would feel right, dark mode, font sizes, screen traders, etc. accessibility would "just work" 98% of the time, the app would be fast.

On Android, things are a tad bit more complicated, but it still applies that the closer you are to the OS, the better things work out of the box.

But for some reason, companies, their designers, product owners, developers want to get creative, use their brand but eventually they always run out of time to implement things properly, so apps are slow, user's font scale settings are not respected, dark mode is a feature, and the app doesn't feel like part of the same phone / OS.

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

I don't know what the situation is right now, but for the longest time ever standard win32 controls where even less useful and more anemic than even the standard web controls. There was always a disparity between what the OS gave you and what the actual good controls MS Office team would think of (until ribbon, but the original ribbon actually did have a lot of thought put into it).

I agree with you.

Easy styling, including dark mode

I wonder if this requirement has been imposed from above.

When the web was taking off I received designs from the UI architect in the form of VB6 applications. Windows was the dominant platform at the time. Never mind it made no sense in the context of more fluid HTML layouts. This was before CSS.

Since then the web has probably trained the holders of the reins that they can violate user interface norms everywhere.

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.

It's even worse.

Those were only a few options that I considered. After a very long time trying out all sorts of different libraries and at one point even writing my own MFC styles, I figured out that for simple apps there is simply nothing better suited than Dear ImGui.

They decided to go with the option that deviates the most from the standard Windows UI, where there are no native controls at all, and it's a nightmare for accessibility (see https://github.com/ocornut/imgui/issues/4122). I use it for prototyping privately, but I'd never make anything I want to release into the world with it.

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 exact match for the blogger's most critical requirements, specially the customization thing, and there is absolutely no better way to target Windows than Microsoft's official GUI offering, but somehow that one is rejected? Absurd.

Agreed. I had the exact same question.

From the article: "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 what the author is talking about. When they say the C++ code will be translated to the equivalent c#, that's not how interop works at all... the native C++ DLL is not somehow made magically more vulnerable to reverse engineering because you can p/invoke to it.

Depending on if he lives in a apartment some country/cities have laws against doing any work in the appartment that impacts the outside without permission from the house owner.

E.g. you can buy a heatpump but you can't drill the hole in the outer wall.

In germany and austria most if not all windows also either open fully to one side or basically bend inwards so you can't install the ac units you install directly into the windows[1].

[1]https://external-content.duckduckgo.com/iu/?u=https%3A%2F%2F...

edit: qualified the law statement

He also says it's 32C, which is slightly less than 90F.

Interestingly, some people would describe that temperature as only "warm". I recently watched a video of a machinist working in his shop (southern US) saying that it was 94 and "a little warm".

Usually, living in an apartment.

It can be hard to justify the cost of installing and maintaining any form of household cooling in colder areas of Europe. Additionally a lot of apartment buildings don't have them, and most landlords probably wouldn't appreciate a tenant installing one without permission. Evidently heatwaves are becoming common enough now that most people should probably keep a window AC unit ready in case of emergencies though.

As an European from Spain, in south European countries air conditioners are essential(Greece, Spain, South Italy, South Spain, inner Portugal). But in other countries or places it is not really necessary(north of Spain, France, UK, Germany).

Some days of Summer it is hot there, and they are not prepared for that like people of the South of Italy or Spain, and there is chaos.

It is like when it snows heavily in Madrid: https://en.wikipedia.org/wiki/Storm_Filomena In places like Austria or Switzerland it would be routine. They are prepared and it would be not a big deal, but in Madrid it stopped everything for two weeks.

I think his complaint is not that he has to pay money per se, but having to pay several thousand dollars. That's a bit much for an independent developer.

Agreed. Also didn't get why he felt complying with the terms of the LGPL for a statically-linked .exe would be so much of a problem. Just put the object files and build script in a zip file, and upload it to the same webserver where you plan to put the program. Add a line in the "About" dialog (or whatever) pointing to it. Done.

No, it makes perfect sense to complain about paid software libraries because it inevitably makes getting to them a huge pain in the ass and that causes folks who just want to easily give the library a try every reason to go try something else. Then as a result the ecosystem of apps using sad framework begins to stagnate.

Exactly this.

Qt is amazing, so if your requirements are so strict in terms of space and you know/like Qt, investing in the license, or make the product open source, shouldn't be an issue here.

need to agree on a GUI interoperability

I hope they don’t. I like that the different platforms I use feel and look different. In fact, I wish there was more variety. I wish there were still Atari, and Amiga, and BeOS, Tandy, and all the other interesting platforms competing for users with different ideas of how computers should work.

This exists. It's called wxWidgets. It's an API shim over native components plus some convenience classes for abstracting out OS-specific functionality. It's LGPL with static linking exception, so no DLL hell.

I'm not quite sure what you mean by open spec, but it's just an API not a protocol, and uhhhh.... https://caselaw.findlaw.com/court/us-supreme-court/18-956.ht...

I think OpenStep actually had something like this in mind and had a Windows implementation too. It's apparently even used in Apple Windows apps like Safari, but of course it must not be complete enough to be able to fully replace native Windows API, and the incentive isn't there either.

Windows (MS) and OSX (Apple) need to agree on a GUI interoperability API. Either hammer something out, or adopt one/more of the OSS GUI framework specifications from QT and GTK.

I've been saying for a while now that the open source world would have benefited if more effort than what went into GNUStep had been focused on copying Cocoa to the point that it rather than GTK or Qt had been the toolkit of choice for the Linux Desktop. Especially when there was a major infusion of interest circa 2010 of folks adopting the MacBook Pro as the developer machine of choice.

I think it's still doable. And I mean down to looks, too, and not just API feel. Aqua from the same time period (Snow Leopard through Mountain Lion era) is the closest thing I can think of to timeless visual design.

It's true that if everyone just made Cocoa apps that looked like they were created with Mac OS in mind it would look out of place on Windows and elsewhere, but (a) it would still look rather good, and (b) it would not look any more out of place than anything else, including Electron and even lots of "native" apps, due to the proliferation of toolkits described in the article not to mention the Gnome identity crisis that has only just recently begun to get reigned in—mostly by following Mac OS cues and being more consistent than before. It's just a shame that it stops at the surface level and doesn't carry over into the actual APIs. Plus those cues are from the post-flattening of UI.

That's called WINE. ;-)

Win32 Hello World messagebox is a few hundred bytes.

they don't need to do this and likely don't care to. web ui exists. microsoft doesn't even care about native anymore. they are focusing on .net maui cross platform/web (with blazor) stuff and AI.

the days of snappy portable applications are over. unless you want to stick with win32. and nothing wrong with that. in win32, you have the tools to create any look and feel you want. the author just doesn't care put in the time to do that and wants something pre-built while conforming to his demands.

IIRC WinG was basically a way to set up a GDI device context that corresponded to a frame buffer, so you could take your DOS SuperVGA code and run it under Windows, only redoing sound and input. It's been almost 30 years though. :)

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

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.

You could just use the standard Edit control for that. If you really want to do it manually, which I have done, it's less than ~300 lines of code for the whole app (including working scrollbars). The binary is less than 4k.

but I never realized that showing strings on Windows is such a PIA.

Are ExtTextOut and related functions all that hard to use? How much simpler do you think it could be?

That book is worth gold from Windows game development archeology point of view, it is quite hard to find anything related to WinG online.

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

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

Where did the idea come from that starting with a 40MB exe is small? That's completely outrageous. You could embed all of python, tk, fltk, wxwidgets and pyqt and still not be close to 40MB.

FLTK static binaries start at 100KB, win32 binaries can start at 1KB, Juce is about 2MB.

Using GLFW or SDL for an openGL window then using IMGUI would start at a few hundred kilobytes.

What are you doing in there that makes your binaries 100x times as big and why would this be a selling point?

Can be compiled statically in a single .exe that is smaller than 40M.

That's... quite a high bar. Last I checked even a QML app was only like 20 MB. Why so big?

Thanks for the link, slint looks really interesting. As someone who's never made a GUI app would you consider it an "easy" task to make one using slink? Also I didn't see any results when searching the documentation for titlebar, is there any way to theme or change it using slink? TIA!

I've been evaluating GUI frameworks for rewriting the editor of a cross platform (Mac Windows Linux and web) game editor I maintain, and this looks worth a shot, thanks for sharing here!

I want to move away from the ancient allegro GUI we use, and so far have evaluated ImGui, RmlUi, and Qt, but so far not totally sold on anything.

Wasn't it mentioned in an HN post or comment somewhat recently (like a few weeks ago)? I think I saw it then, and checked out the site and a few demos at the time.

I'm going through the documentation right now, and I'm a bit confused. How would I integrate it to use for the WInforms UI?

Anyone can compile a static binary with FLTK and have the binary size start under 100KB.

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 supports dark mode/theming out of the box along with fully customizable styling. It's as free as it gets. It's also Microsoft's official GUI framework for Windows. But the blogger rejects it because... Because what?

nuklear solves all of these for me, plus it's plain C

.NET since 6 (I think) can be published as a self contained app with the runtime included.

It immediately adds some size to the output but you can mitigate it with AOT and trimming.

No go for net 4.6 which is installed on every currently supported Windows version back to the original Win10 released almost a decade ago.

There are still people running Win 7 but I wouldn't worry about that group having a streamlined experience. With 4.6 they can still install the runtime manually.

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.

.NET Framework 3.5 is no longer installed by default starting with Windows 10.

C# with WPF or WinForms only seems nice in comparison to other relatively painful tools IMO.

The old RAD graphical tools and newer ones like Rebol (that are now dated) show just what is possible. Mathematica is also pretty powerful and doesn't require a ton of code.

The painful bit is C++. I did a fair bit of that going back to MFC.

I'm sorry but referring to MFC while referring C++ is a telltale sign you don't really have any meaningful experience in the field. Developing GUI apps for Windows is a breeze with frameworks like Qt. You only suffer if you're a masochist, but the rest of us prefer to pick things that make sense.

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

I have been trying to learn WPF for a long time, but have drifted into web apps.

Can you point me to any good resources to be able to make complex multi window apps in it?

I have good experience in Windoes forms and am well versed in c# and dotnet.

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!) then to UWP (monster controls for touch I guess?) is honestly mind blowing. The emphasis on Universal Windows Platform as "the future" of app development is absurd. Every time the design language behind this infects another settings app in windows we LOSE functionality! Can you even have more than one settings window open anymore with the new and improved UWP?

Then there is WinUI? Then there is MAUI? THen there is blazor on the desktop?

Has Microsoft confused you yet? They've confused me. Each of these introduced as the best thing since sliced bread, and back with tooling with broken forms designers and more.

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.

Writing GUI apps is painful everywhere, and has been for years.

Disagree. GUI development on Apple platforms using either UIKit or Appkit is something I've always found expressive, simple, and fun. SwiftUI is a different beast, but to say it's painful everywhere is not accurate.

Flutter is actually quite nice and works well on desktop too. If Google continues to develop it I could see it becoming the first choice for a lot of developers.

Writing GUI apps is painful everywhere, and has been for years.

I think UIKit and SwiftUI (and to a lesser extent Appkit) are great

Today UI apps use 100X more memory,

Larger memory footprints aren’t just from the GUI. There is a lot more functionality to deal with everywhere. Just handling modern security, encryption, and certificate checking stack can take up more space than entire executables from the early 90s.

I also have literally 100X more RAM now.

are slower,

Im fairly certain everyone who says this has simply forgotten how slow mechanical hard drives were. I occasionally have to pull out a very old laptop, hope that it still boots, and do something on it. Everything is so painfully slow in ways I forgot about. It’s refreshing to return to my modern PC.

and are harder to use with little to show for it in terms of improved functionality.

If you don’t think modern apps have more functionality, I don’t know what to tell you.

Say what you will about VB6 but it was stupid simple to get GUI apps up and running.

runFullTrust apps are still subject to file system and registry redirection as well as various capability checks. Running fully unencumbered requires restricted capabilities that only Microsoft can approve.

Where's the GUI designer?

WinUI 3 XAML C++ is a joke, versus the old C++/CX tooling in Visual Studio.

Editing IDL files without any kind of Visual Studio tooling, manually merging generated C++ code, no designer.

For >1 minute incremental compile times? No thanks.

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.

No idea about Apple, but I'd strongly disagree for Microsoft. In one way of speaking, they invest too much. WinUI3, like the article mentions has such a sordid history. It started as WPF, and WPF was (is) awesome. It's simple, clean, runs on a bunch of different platforms, doesn't have a zillion dependencies, has a great community, and is just all around pleasant to work with.

So naturally Microsoft decided to completely scrap it, replace it with a far less functioning successor, flop, and then repeat this process over and over til we get where we are today after WPF->UWP->WinUI2->WinUI3. And WinUI3 has also already been completely abandoned. Contrary to this article, it still doesn't even have a visual designer. The amount of time, energy, and money Microsoft has spent with all of these successors is going to be remarkable, just to keep throwing everything away and restarting.

Oh and while all of this was happening they've also been developing Xamarin, MAUI, and more that also all do pretty much the same thing - in completely incompatible ways, with a similar general trend of having the attention span, focus, and overall quality of a 13 year old ADHD boy, in a Japanese arcade, after 7 shots of espresso. This just isn't the sort of thing you could do without just completely absurd budgets and minimal concern about actually making something great. If they had instead just stuck to perpetually refining WPF, UI development on Windows would be a utopia today, and they probably would have saved an immense amount of money, or at least manhours.

While Apple could stand to improve some aspects of their UI toolkits (and you're right that private widgets have long been a frustration), I'd say they're in an entirely different plane in existence relative to Microsoft in this regard.

The most solid of their toolkits is far and away UIKit on iOS. It's got almost all of the best parts of AppKit with over a decade of thoughtful tweaks, polish, and QoL improvements. AppKit has become a bit more neglected since iOS stole the title of favorite child from macOS but is still quite solid. Both have an extensive set of highly capable stock widgets and with both, you can write just about anything imaginable pretty easily without importing a single third-party library. Neither locks you into a WYSIWYG editor or hand-editing XML and are pure-code-friendly, particularly since the addition of autolayout anchors.

SwiftUI is finally getting to the point where it's not so green and is becoming a more practical choice. Though it wasn't a headliner, this recent WWDC brought a number of long called-for improvements.

By contrast, WinUI lacks such fundamental basics as a tableview/datagrid, meaning you're going to be rolling your own or importing third-party widgets much more frequently. While you're not as locked into XML layouts and resources as one would be with Android Framework with it, it's not as friendly to pure code. It's also decidedly mobile-esque relative to AppKit (likely owing to its UWP heritage) which might be a problem if the goal is to build a true desktop-class app.

Writing GUI apps for Windows in C++ is painful

I don't think so. Qt makes this a trivial problem, and WinUI3 supports C++ as a first class citizen.

I'd argue that desktop development for Windows was never as good as it is right now.

Delphi comes with so many db drivers, a data layer that will let you do crud, and an app store that using it feels like cheating. Especially with devexpress controls.

lazarus is great, but the GUI library it comes with has the same issues that the author is concerned about... try changing the theme colors to a dark theme... you end up with something looking like crap with all the other controls using standard colors.

A. imgui and SDL2

B. imgui and SDL2

A. PureBasic

B. PureBasic

If money was not an issue, I'd probably try Delphi for both A and B, which can create native cross platform apps.

If not, I'd try Lazarus for A and Kotlin compose for B A: Lazarus or Delphi (if money was not an issue)

B: Kotlin compose or Delphi (

libui libui

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.

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 of them in favor of theme colors or images. Menu colors, for example, are ignored when theming is enabled.

The result is that if you want something approaching a reasonable dark theme with Win32 stock controls, you will often need to resort to full owner-drawing of the controls. This is not a minor task.

The issue is the React paradigm, which is a bit questionable to begin with. It's a sort of fake OOP in a trenchcoat pretending to be something else, whilst abusing the language in ways that requires compiler plugins. My experiences with Compose and SwiftUI have been ... not that great. I kinda wish people would just have kept investing in their OOP toolkits.

Kotlin wasn’t designed with Compose in mind. They shoehorned it via compiler plugin.

The explanation is easy, the usual WinDev versus DevDiv politics.

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, like window management, it's much more crucial, that it is for other things, like roundness of buttons.

except in highly specialized software with workflows dependent on prior user experience, such as DAWs

It's not just about prior user experience. If a custom control enhances UX for a specialized task, it has a good reason to break some of the consistency. All specialized software (DAWs, graphics applications, IDEs etc.) have such features. Limiting themselves to just native components would lead to a suboptimal user experience.

Yes full agreement from me.

I think loads of energy is wasted in development because someone wants custom stuff like buttons or input boxes without real reason where off the shelf GUI would work and would be much cheaper.

What about a simple dark mode, that even the OS provides options for?

I love GTK, but compiling it on non-native platforms is torture. If you're lucky enough to get a build environment working, compilation can take hours just to yield a horribly buggy and slow GUI.

I really wish GTK worked better cross-platform, but I mostly use it for Linux-only stuff. It's not humane to make Windows and Mac users suffer through it, unfortunately.

GTK programs look very out of place in Windows.

So much time spent on creating many different web frameworks to try and replicate the snapiness of native applications when the solution was to make native applications use web-tech so that both are equally slow. Mission accomplished! Genius!.

You just redicovered HTML applications from Internet Explorer 5.

Greetings from 1999.

https://www.developer.com/guides/ie5s-html-applications/

Yeah I thought of this too. Wrapping this with Tauri should not be too hard, and quite space-efficient

And C++ Builder as well.

Some day I wish for someone to rebuild Lazarus with go and yaegi.

Then I would never use anything else ever again.

Lazarus' UI component library is beyond amazing, and growing up with it as a teenager made me realize how bad everything else is in comparison.

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 features which convert declarative syntax into imperative/object-oriented C#. The truth is that the vast majority of people who work on user interfaces are not the kinds of software engineers who enjoy this; HTML's model of creating arbitrary blobs of flexible dom nodes (and then using javascript to handle user interactions) is a lot more pleasant than getting compilation error after compilation error in XAML and having to google how the hell you display a set of items in a ListBox, only to have to filter through 4 or 5 different slight variations in the proper types between WinUI 3, WPF, UWP, and Maui.

Native desktop software will never beat web browsers as long as you're forced into using the framework's model for structuring your data and code. 13 year olds learn HTML, CSS, and Javascript, that should be the target for usability with native UI frameworks

No one wants to talk about it or Delphi anymore.

Programmers are just as fashion-concious as the Milan catwalk designers.

Wouldn’t that be excluded due to cost?

It strikes me that having the C++ requirement is part of what makes this difficult.

It doesn't.

In fact, it makes the problem even easier to solve due to the options that are already on the table. Virtually all .NET-based frameworks support C++ besides C#, specially WinUI3.

Are there serious issues with wxwidgets? When I was looking for this sort of things it was unglamorous, but had decent bindings with several languages and looked decent enough. I agree with your assessment of the other alternatives.

if you can compromise on the 40MB size requirement then Electron should be a good fit to cover all your other requirements.

Microsoft also supports React Native, which is arguably way better than any webview-based approach.

A second recommendation for Avalonia. It deserves the acclaim.

Uno is closer to a full stack rather than front-end in comparison with Avalonia.

I agree with the sentiment of your post.

Real question: Is a single exe not possible when targeting .NET Framework 3.5? Or is the problem that the sum of their silly requirements makes it impossible?

It's a real engineer's way of looking at UI, as a necessary evil to have the user use the "real" part of the software

I agree.

Also, in my experience, writing UI code is usually more(!) work than writing the functionality underneath, because

a) styling / layouting has to be learnt from scratch (e.g. because of a proprietary language, e.g. QML or QWidgets for Qt)

b) you have to take care of every frikkin' single user interaction (which becomes worse the more dynamic and custom your UI is), and building proper accessibility is also no walk in the park

Yes it also works on MacOS, and web as well.

What was your problems when using Flutter for desktop? For me, it's the lack of multi-window support. There's a community solution but it's a bit lacking because it spawns another engine while the upcoming official solution uses single engine.

I personally use it for my desktop apps (cross-platform) and building UI for it is a breeze. Though I forked someone's window styling plugin because it's missing some features I need. A native dev would've done better than me but if it works it works I guess.

If I had to satisfy the requirement in the post though, I'd use enigma protector with to make the app folder into a standalone exe and with compression enabled to make it smaller.

Probably the best option for the author, bit surprised that this was not listed as option, especially since he considered writing HTML/CSS for Sciter.

COM interop now works on NAOT with source generated COM wrappers: https://learn.microsoft.com/en-us/dotnet/standard/native-int...

(it's unfortunate the milestone is set to future in the linked issue though, which includes the light-up for the feature above)

First of all, this is an immediate rendering library which is a very inefficient way of rendering the UI for any application that is not a videogame. You are rendering the UI 60 times a second, regardless of whether something changed or not. Most UI frameworks only update when something changes.

Secondly, there are things in GUI frameworks that most people don't think about, such as accessibility. Windows has a builtin accessibility API where apps can declare the objects being shown on the screen, so that screen readers can interact with the application. I'm pretty sure this guys framework doesn't have that.

Every OS/environment should have a GNOME Builder equivalent.

UIKit has a few frustrating details, but overall it stands tall above the competition.

For a long time the main downside was that you had to deal with Objective C, which is a turnoff for some people.

Swift solved all this, and writing UIKit in Swift is mostly a joy. Sadly now SwiftUI is the new shiny thing, and it’s a major downgrade in most dimensions save for a few.

A cross platform framework that reuses UIKit conventions and supports all modern languages (C++/Rust/Go/Python/Nim) would be the dream.

Styling functionality doesn't have to imply introducing a new look and feel, it might just be needed for extensibility.

Yeah, I've done custom skinned apps in WPF that were deployed via zip file. Unzip and run the exe. Worked fine and even did p/invoke. Either they are ignorant about MS windows development or just a fanciful idea about how it should work.

Why do you think Qt isn't fast? Qt apps can be VERY fast. My block editor[1], written in Qt C++ and QML is 4x faster than Bike - a native macOS app - that is already very efficient and performant.

[1] https://www.get-plume.com/

Oh god, seeing TkInter applications, and inevitably, having to fix them particularly on macOS just fills me with rage. Whoever reads this - do not use TkInter.

This looks quite promising! I love LUA simplicity and I've always wondered if I could built commercial-grade desktop apps with it. So far I only considered something like LOVE, but LuaRT could be a good alternative.

it won't. at least not with the color theme requirements. and if you don't care about those, you might as well use win32 controls.

If you hate your users, sure. For anything more than a toy please use a real GUI framework.

Do you have any actual real criticism?

I was going to suggest embedding the native WebView ActiveX control (which I did in the past with great success) but it turns out the WebView has been updated and wants end users to download and install the Chromium-based runtime library nowadays.