Writing GUI apps is painful period, and it’s become more so not less in the last two decades.
Go back in an emulator some time and try Visual Studio or even old Borland from the 1990s. Point, click, add code, set style, and the result was not bad at all. The whole UI looked consistent too with uniform controls, shortcuts, etc.
Today UI apps use 100X more memory, are slower, and are harder to use with little to show for it in terms of improved functionality. The whole desktop is a disaster of conflicting designs and accessibility or uniformity are practically gone.
Mobile is kind of shocking too. Here was a chance to dump cruft from desktop and do things better but the result really is just as much of a pain in the arse if not more. Consistency is a little better but the developer experience is awful and of course unlike desktop you really can’t develop on the actual device. That adds another layer of shit.
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.
> Im fairly certain everyone who says this has simply forgotten how slow mechanical hard drives were.
Absolutely, but I would go even further with this. I can't prove it, but I would bet a lot of money that Windows 10+ has made using a spinning disk even slower. I would guess optimizations around disk access were entirely different in the XP era compared to now, when it is assumed everyone has an SSD.
Anyway, I had an old laptop that ran like absolutely dog shit. I put an SSD into it and it magically became usable again.
I assume OP means slower on like-for-like hardware, rather than slower when run on a PC from the 90s, but to be fair the WinForms/WPF component of old GUI's was very fast even on legacy hardware.
> 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.
What does this have to do with bloated GUIs?
> 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.
I remember 98/XP running circles on mechanical harddrives compared to modern PCs on ultra fast SSDs. The fact that despite thousand times faster hardware we have slower performance is disgusting.
> If you don’t think modern apps have more functionality, I don’t know what to tell you.
Care to provide an example what modern applications have that older ones lack? Except for always—on connection and artificial bullshit imposed by modern OSs.
It was stupid simple to get simple GUI apps up and running. More complicated apps were impossible. But, I think that's exactly what's missing in the Desktop GUI market right now. Webapps are incredibly easy to start apps with. You only need to know a few things and you can pick up the rest later as your app gets more complex. Modern desktop GUI systems are incredibly complicated, in comparison, just to open the window, let alone put text on the screen.
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].
Are portable AC units not available in Europe? They are inefficient but can sit inside next to the window and only require that you partially block off a window opening.
I don't know what landlords are like in European countries, but some landlords in America forbid people from connecting any kind of AC exhaust port to a window.
It's funny that in this case the law now protects you.
Generally anything you do indoor that falls under normal usage(painting walls, hanging furniture with big screws,etc.) is ok without approval, at least in my country/city(austria) and the land lord can't deny any of this and is not even required to be notified.
As you would have an open window and a not so noise machine running this would be ok, but energy efficiency is quite bad and you lose the benefits of the thermal insulation of your building.
Yeah, the GP comment is classic HN. Wildly vague, with no supporting evidence. The planning rules in the US are fractally complex compared to "Europe".
Power isn't cheap, and inefficient is an understatement. In the heatwave last week in Germany I managed to get ours to cool a tiny bedroom from 30 to maybe 26 degrees Celsius.
Doesn't help that in new construction outer walls are usually very well insulated, and inner walls and floors aren't (by design; 70% of total heating cost is evenly split too), so you're working against your neighbors too. We have some stupidly complex building standards often driven by industry lobbying (which also makes building expensive), but installing a mini split hasn't made it on the list.
Works just fine, I have 8000 BTU and it cools a living room very efficiently. I need it about one or two weeks per year in Finland. I can't imagine anybody working from home without one, even as north as Finland. Although we Finns are probably least used to heat so even 27 celsius is unbearable.
The only thing one needs is a window-sized cardboard with a round hole and blanket if your target room has no door. I just looked at prices and 10000BTU seemed to be ~350 euros.
I bought a portable split system for 2400 EUR. Works pretty well since I have shutters and a balcony, I put the external part outside the window, pull down the shutters and seal the lower part of the window around the pipe with some stuff. Doesn't use lots of power if I cool to 26C. Well, today we had 34C outside, so it had to work a lot.
Sure thing: https://www.amazon.de/-/en/gp/product/B07YZ5XT92/
Maybe it was a bit less, 2200 with shipping.
I do have a top floor apartment looking south, so I get a constant 30C+ in summer, without any cooling at night.
They definitely exist, and are very cheap. I got one for 200, gave away to a friend when I moved out of an attic apartment. They have a window-attachment accessory that makes it easy to attach to those European windows.
The real reason most of us don't have AC is because it's hot for a very short period. Last year it definitely wasn't too hot for me to warrant having one. This year so far, it was, for a week: we had about 30°C (86°F) last week, but next week my mobile phone promises it's gonna be 20°C (68°F) maximum, which does not need AC. Maybe that will change, though.
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.
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".
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.
MSYS2. And copy over prebuilt dependencies. And while we say C++, I suggest always to use Meson as build tool. Which allows you to use WrapDB (built in dependency-manager) aside from available native libraries and own local sources.
The problem about Windows is, that Microsoft adds new APIs repeatingly and doesn’t care much about the previous ones. While on Linux we’ve Gtk1, Gtk2, Gtk3 and Gtk4.
And while people complain about deprecations and changes they actually mean „API changes require work to use the new major. But these people keep maintaining it. And provide upgrade paths to enhanced versions? I’m in!“.
HiDPI, Wayland, new Widgets, new renderers and a scene-graph.
PS: If you need to keep it small and simple and address professional (power) users I suggest a TUI with the venerable ncurses. Or notcurses.
Tested Geany Editor on Windows the other day, it uses GTK, great editor but horribly slow on Windows, just scrolling a small file (less than 100 lines) was sluggish.
+ "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, portable => small, simple application where functionality is more important than dark mode or other styling ability.
You can do that with straight win32 as well. Steve Gibson has a bunch of utilities and most of them are pretty tiny. His DNS Benchmark is one of the larger utilities at 169k.
I like win32 and you can get a lot smaller with win32, but there are a lot of things missing. FLTK has a lot of components, component layouts, fonts, file system stuff, networking, audio, an openGL context, image loading and it's cross platform.
I'm confused. What is "missing" from Win32? To be clear, I count all base DLLs included with Windows a "Win32". One thing I can think of from your list: component layouts. Resizable windows with component layout is awful in Win32.
You can use dynamic_cast instead of reinterpret_cast. If the pointer isn't correct it would return null. A better solution is to subclass the widget, store a function pointer for the callback which takes the same class instead of an Fl_Widget, and call that in the callback:
https://github.com/MoAlyousef/FLMH
This uses a std::function for the captures but you can use a function pointer as well.
> 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?
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.
And those COM errors that just kill the process, bypassing C++, and .NET exception mechanisms? lovely!
No designer, manualy editing IDL files for XAML C++ bindings, without any kind of syntax highlighting or code completion, manually merging generated C++ code, even more lovely.
Using a Webview wrapping Bing Maps, instead of the native UWP map control, even better.
Apple and Microsoft underinvest in their widget toolkits. It’s especially damning for Apple since they spend the money to write numerous custom widgets (e.g., the widgets in their professional apps like Final Cut Pro and Logic Pro) but don’t upstream. Nobody is inspired by yet another implementation of button or tab widgets.
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.
A lot of the best people left MS. People forget that MS was so completely dominant that it attracted a lot of talented people who wanted to do big things. Since then the competition from the FANG companies have brain drained them, not helped by MS insistence on paying less than their peers, sure there is no state income tax but the company shouldn’t be trying to capture all of that difference.
The net effect is that not only are they not capable of building things as well as they used to, they can’t even maintain what they already have. And how would anyone go about fixing such a culture. I think that’s a big part of why MS has been so generous to OpenAI while also keeping them at arms length.
Inertia is incredibly powerful and big companies can remain successful for long after their technical competence dissipates.
> And WinUI3 has also already been completely abandoned.
I'm not sure where you got that impression, but WinUI3 is in almost all of Microsoft's software at this point. Admittedly a huge amount of it is embedded inside React Native, but WinUI3 seems to be the UI toolkit that has won and is still going strong. They announced a bunch of WinUI3 enhancements at BUILD even.
(One such announcement is a coming standard control for the sort of custom Windows Title Bar with a search box and branded logo and extra buttons that has become common in every first-party application from the Microsoft Store app to all of Office and many other places.)
> Contrary to this article, it still doesn't even have a visual designer.
Huh? Visual Studio has a visual designer for the WinUI 3 flavor of XAML. If you don't want to write XAML to back your UI they probably will never support a Visual Designer for you (ie, C# UI seems neat and maybe a bit more "functional programming", but I'd rather use XAML just to have the Visual Designer at least). Last I checked the XAML designer works just fine even in C++ projects targeting WinUI 3.
Visual Studio's designer really does not support WinUI 3. Try it! Hot reload also doesn't work worth anything. There's an ongoing issue/discussion on Github here [1] from 2021. There's also loads of fundamental issues like various controls causing replicable crashes with drag and drop, the community calls are disappearing, and more.
Sure, it is definitely very buggy, but the point is that it still exists and is useful to some extent. I was refuting the claim that there is *no* visual editor, not the claim that the visual editor we do have is maybe deficient and buggy.
Relatedly, I still think it is something of a shame that (Expression) Blend didn't survive to the modern era. A designer-focused XAML design tool that doesn't need a full Visual Studio install (nor the same sort of expensive VS license) and feels more like Firefly or Figma or whatever other designer-focused tool is current en vogue would be really handy in a lot of situations.
I don't think it is the only reason that designers tend to prefer HTML (and thus we use Electron or similar to placate the designers that think that "just copy and paste it from the design tool" works "well") over XAML, but it certainly doesn't help that there isn't a "XAML Figma" and it's a shame on multiple levels that Microsoft recognized that threat early on, built a solution, then got confused why they built it, confusingly merged it into Visual Studio licenses and installs, which lead to its sadly inevitable death just a few years before it would have been very helpful to have to send to some designers and stop getting HTML-only mockups.
To be clear I am saying that drag and drop operations do not work during runtime. The designer literally does not work at all, for WinUI 3, for reasons that are not at all clear, since Visual Studio had a 'native' designer for WinUI 2, as well as the weird disconnect with Blend as you mentioned.
I almost feel like you're mixing up WinUI 2 and 3, because the designer was kind of borky for WinUI 2 but did work, and was overall an okayish experience. But for WinUI 3 it's an entirely different game. Early on the messaging was that the designer would be "coming soon" (tm) and that people could just use hot reload in the interim, then at some point hot reload ended up completely broken as well, Microsoft gradually started withdrawing engagement with the community, and here I am saying it's been defacto abandoned.
The point of the designer is not just mock ups. At many (most?) small businesses and studios the developer/designer dichotomy doesn't exist. There's a reason lots of companies are still even using e.g. Winforms. A high functioning designer simply dramatically improves both productivity and quality.
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.
The painful bit is C++. I did a fair bit of that going back to MFC. Knocking stuff out in C# with WPF and WinForms was quite nice in comparison. I haven’t found anything nicer.
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.
I think there is a thing called Microsoft Office development kit or some other name that allows C# and other .Net programs to manipulate Office apps. Not sure if it's what the author meant, though.
Oh, I have used OLE (or some iteration thereof) to drive Excel from Python. That was a long time ago, but it sounds similar. I wasn't really doing GUI, though - I was using code to build spreadsheets from data files.
I had something I wrote in the 90s I wasn't proud of that was a word macro that read Excel sheets for a list of instructions and used those to compose documents and print them. I feel sick thinking about it.
> 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.
I have a lot of experience, in the real world, which is somewhat less ideal than "just use Qt - it's a breeze".
How do you manage a 15 million LOC desktop app originating from the late 90s which contains chunks of win32 native, ATL, MFC, custom GDI+ wrappers all sorts?
Aye you fuck off and work somewhere else that's what you do. Which is why it's still written in win32 native, ATL, MFC, custom GDI+ wrappers.
They paid two companies to come in and rewrite it, first in Qt which was a complete failure. Then in Electron etc, which was also a failure.
> How do you manage a 15 million LOC desktop app originating from the late 90s which contains chunks of win32 native, ATL, MFC, custom GDI+ wrappers all sorts?
You're complaining about your personal legacy "chunks of win32 native, ATL, MFC, custom GDI+ wrappers".
Not C++. Just your personal legacy projects you didn't managed to maintain or update.
C++ doesn't magically rewrite your technical debt. You need to do your work.
Ooh I remember having a 'Windows API fundamentals' elective at college. I wrote an app with a couple buttons, menu and scrollable text area, but not much in terms of functionality, in pure C, that was all around well-behaved. It was more than a thousand lines.
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 40MB limit also rule out a lot of options. The author admits that Qt could have met these requirements but the open-source licensing part wasn’t compatible with his goals and he didn’t want to pay for a license.
If you relax the requirements to tolerate some dependencies, allow larger download sizes, or to simply use built-in Windows GUI controls the situation is very different.
For writing a lightweight, completely custom GUI with no external dependencies and permissive licensing I could have guessed ImGui would be the answer before I started reading.
> 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.
True, but they are optional and are not the parts you need to create a GUI as per the requirements in the OP. I assume CopperSpice does not include these components.
I never understood the need for a single executable on windows when folders, zip files, and 100% free installers exist if you don’t like zip files. Also nearly all of the gui kits he’s shooting down have ways to build custom components if that’s what you want to do.
No need for an installer when it's just one file you can run anywhere. And folders/zips are way too hard for the average user. Ask me how I know. My partner gave up an entire game platform because it was delivered as a .7z file they could not figure out.
None of these help you if you are dealing with users that move executables for convenient access or think updating the sofware just involves dragging and dropping the new executable into the existing installation folder. Customer support had countless stories like that.
Does using something like APE by jart work? It's a single executable that's also a zipfile. (I assume a replaceable .dll inside the archive is LGPL compliant) I know it's a bit of a tangent, but on platforms like macos the "apps" are all directories with the .app extension, and that doesn't seem to cause issues.
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 normal static linking, it's only a bit harder. 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.
> 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?
> 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.
Do you need to ship it alongside or produce it on request or link to where they can fetch it? It's not like you need to ship source code alongside either for GPL binaries.
Does this also mean that one could put most of the closed source part into a DLL, make a shell executable that is open source and statically link LGPL code into the latter? This then would allow modifications to the LGPL code to be put in just by having the closed source DLL.
You’re not getting a size reduction if you maintain a library boundary, though. What you’re doing is isomorphic to dynamically linking except the app code is in the library and the library code is in the main binary.
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.
Because adding a text is just a imgui::text("abc") function call. And a button is just an if(imgui::button("click me")) do_something() statement. There is no other language involved, no markup, no gui editor. Just direct code and highly hackable to make this extend to unexpected lengths.
To add to this, I find it easier to have a simple while loop that renders the screen, fetching variable data on-the-fly, etc. It is rather pleasing to the eye to understand the layout with IM interfaces, etc.
Comparing this to (something like) WPF, you create XAML files, with either or combination of ViewModels and back-end code to "bind" and can get complicated quickly. I guess the only exception to this is if you have commited to WPF non-stop for many months. However, with IM interfaces, its easy to get going (imo)
Most games don't use ImGUI, though. Like the parent commenter said, it's useful for debugging, but the actual in-game UI—HUD, inventory, map, etc—is usually rendered by yet another middleware framework like Scaleform, or something that the engine provides (Unreal or Unity).
Nuklear is sometimes used. Anyhow, I do know of some game engines created and used by a (very large) game studio that uses ImGUI. I won't say anything else though :)
This is true. There is a reason why Scaleform made its way to become a popular gaming UI framework even though many of its weakness. The most important focus in game UI framework should be on tools and pipelines for artists/designers and this is usually not up to engineering decisions. I won't say that using ImGUI for game is impossible, but there might be lots of tooling works ahead for production game development.
There is also furnace[0] and mmlgui[1]. Which are recently developed programs that people have been using to create chiptune music for retro video game consoles. Including being used by Yuzo Koshiro[2].
Excellent reply. I did not consider international keyboards when I writing my reply. And gaming companies are definitely targeting international markets in 2024!
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 indeed. Custom UI widgets for Windows apps are really not necessary most of the time, and fitting in with the system theme is all you ought to aim for, most of the time.
There are exceptions, for very rich dense UI, for UIs that need to be cross-platform, but if you're writing a Windows app, it should look and feel like a Windows app.
Most applications would be fine with a button on Windows looking like a Windows button, a button on Mac looking like a Mac button, a button on Android looking like a Material Design button and a button on iPhone looking like a UIKit button.
You need consistency in the icons, layouts and concepts, but you don't need every widget to look exactly the same on every platform.
Is your app as large and important as the OS of the device (Chrome/facebook/etc...) you should probably have similar language across devices.
Is your app very large but not that large? (Slack/teams come to mind) I think you can go either way.
If you are smaller than that (hint: you are) then you should comply with the design language of the platform, even if that means somewhat large changes such as moving buttons from the left to the right. The likelihood that users are constantly using your app on a iphone and android is really low.
I disagree. I think the only apps where a custom UI make sense are games and I’m willing to accept highly specialized business apps that have their own conventions. Thinks like Blender, AutoCad, Logic, etc.
I’d still like to see them try to match a little, but they’re specialized enough I get that may be a better path.
Chrome? Facebook? Slack? Teams? No.
I’m not saying things need to look like MyFirstWin32App built with VB6 in 20 minutes.
But use the system controls and conventions. Custom colors and layouts can be fine. But if you want to make your own UI toolkit then make your own OS too and leave my computer alone.
> Is your app as large and important as the OS of the device (Chrome/facebook/etc...) you should probably have similar language across devices.
No app is more important than the OS, and certainly not Facebook (which has no business being an app in the first place). I made a choice when I got the OS, and I like developers respecting it and not chase the fad of the day with poor approximations of the native widgets (text fields that do not support standard shortcuts, buttons that do not behave as they should, labels that do not support accessibility features, the list could go on). Even huge apps like Photoshop or Office get this wrong everywhere.
I definitely agree on the default (use the native toolkit), but there are no applications big enough to get their own behaviour. Open Source or hobby applications get a pass if the UI is a bit wonky, but that’s about it.
> Does Microsoft themselves build their apps this way?
I'm not sure anyone could really answer this question considering how fast Microsoft's various silos pinball between UI conventions. All of them are (I would hope) based on various iterations of their own internal tooling, but looking from Windows 7 to 8, 10, and then 11, you get such stark differences in UI language that you feel like you're looking at competing products.
That being said, I would personally very much prefer apps that are built to mimic the system they are a part of. One of the worst sins of that one, IMO, being iTunes on Windows which has always been and continues to be a flaming dumpster fire for a number of reasons, but most especially it's UI. It is a Mac app that is parked in Windows. It looks like a Mac app, it operates like a Mac app, it's UI conventions are that of the Mac, with the one major difference being they stuffed the window controls in the window in an incredibly slapdash way to account for Windows not having the system bar.
But yeah, for any marketing people here, I have not once nor will I ever give a single molecule of a shit about your brand identity. Make your software good. Ideally make it mesh with the system it's in. I couldn't fucking care less what color everything is.
I, for one, miss customized installers. We've kind of lost out on those what with the move to digital distribution.
Gone are the days of my friend accidentally having his volume cranked when he inserted the Red Alert 2 disc, not knowing it would blast out "WARINING! Military Software Detected!"
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.
I recently built a small app using SwiftUI. It was my first, and pretty simple.
The documentation was absolutely maddening.. Half the time the Apple docs referred to a previous version. “Do this thing in XCode” often included screenshots of UIs that don’t exist in the current version of XCode. Examples I found on Stackoverflow or random blogs were usually no longer applicable.
It felt like magic when it worked, all those VStack HStack nestings, but the annoyance of finding my way there made me seriously doubt whether I’d build a big app with SwifUI, especially if I wasn’t working alone.
Thanks for the follow-up. These types of anec-data are the best part of HN.
> It felt like magic when it worked, all those VStack HStack nestings
I know the feeling from Qt. I think Gtk and many other GUI toolkits use the equivalent of VStack and HStack to make resizable GUIs. Some GUI toolkits try to avoid this problem by using a grid layout, but it is more rare.
EDIT
> made me seriously doubt whether I’d build a big app with SwiftUI
From your experience, what GUI toolkit would you prefer? And, it would help to know what is your target UI platform.
Did you do cross-platform and if so, did you use the same UI style for everything?
Today I was making a list of reasons/excuses for using Material Design on Mac… which I guess would make some people mad, but it might work for an enterprise product.
Yes cross platform and the same style. I don't think this matters much to users today. They're used to it.
That said I did do a fair bit of my own theming. The Flutter Material widgets are actually pretty customizable and I'm not a big fan of vanilla Material.
I don’t have much app experience, I’m mostly a back-end guy trying to build some prototypes and (hopefully) one product.
I’m not in a position to give anyone advice, but I’d love to find SwiftUI but cross-platform and usable from anything other than XCode (well maybe not Ed…) and native GUI and a pony.
For my product I need to support Mac, Windows and eventually iOS/iPadOS. For prototypes iOS is enough. I don’t mind learning new languages for this, but ideally there would be some advantage in knowing the language itself. I’ve been looking at lots of frameworks over the past month.
The most tempting thing so far is Flutter, but I have nagging doubts: because it’s not native UI, I worry about that being a no-go for some large customer down the road, and also about alienating power users. I looked at React Native but it’s not very good for desktop yet as far as I could tell (and the demo app from the documentation doesn’t work, which is a bad sign). Which is too bad because I was impressed with Expo, if I just needed phones I’d probably use that. I looked at Avalonia but it has the opposite problem.
Today I’m looking at Tauri for the Nth time: at least I could improve my Rust, and it seems to have momentum. Doing the UI in a web view is kinda sad, though, after trying SwiftUI.
Just building multiple apps is not realistic, I’m a solo dev and want to get this to market in my lifetime, and it only makes sense if I have both Mac and Windows.
Very happy to hear recommendations from people who have done this!
If you really want native look and feel then really your only choice is to use the native toolkits.
I'm not convinced many users care that much about this though. They spend most of their day using apps that don't use native controls and I think they're all pretty used to it by now.
I prototyped a bunch of different desktop toolkits and I think that today Flutter is by far the most polished and mature. I've had overall a very positive experience using it for my music app:
The threat of Google canceling it is real though. I suppose if that happens I'll switch to Tauri or just give up on Windows and Android and do SwiftUI. My experiences with SwiftUI to this point have not been very positive though.
Kotlin Multiplatform might also be an option at some point but it doesn't seem that close today. Unfortunately it seems like none of the os vendors are making their desktop APIs a priority these days.
Thanks, I will have a look at that. Serendipitously, I'm in the market for a new music player!
Yeah the Google risk... seems like they came out strong in support of Flutter at their last dev conference, but at the same time it does _not_ look like they're using it for their main apps.
Without expressing an opinion on Flutter as such, it's worth remembering that Google is a big enough organisation that even -some- internal apps being built using it is quite a commitment, and it not having spread further internally could easily be a social or political rather than a technical issue.
I don't think it it's a technical issue. On a technical level Flutter is mostly great. But Google has been doing aggressive cost cutting lately and not having Flutter in use in that many apps makes it more vulnerable.
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.
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.
A nice thing about .Net Framework 4.8 is that they finally finished it! No more update treadmill and dicking around dealing with what versions are installed or how to configure your application to use whatever different versions. Just target that and forget about it.
.NET 4.8 is the last .NET to be bundled with Windows. It's a legacy stack, but it exists on every Windows >= 10 so it is a legacy stack that makes deployables easy (just assume it is installed). (.NET 4.8 is the new VB6.)
With .NET 9 right around the corner, how far behind the legacy stack is only increases.
.NET > 5 will never be installed out of the box on Windows PCs. The trade offs to that concession however are: cross-platform support, better container support, easier side-by-side installs support ("portable" installs). .NET > 7 can do an admirable job AOT compiling single-file applications. For a GUI app you probably aren't going to easily get that single-file < 40MBs yet today, but it's going to be truly self-contained and generally don't need a lot of specific OSes or things installed at the OS level. Each recent version of .NET has been working to improve its single-file publishing and there may be advances to come.
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)
Except it's still missing a lot of controls, further development and bug fixes are practically at a standstill, and despite what TFA says, there is no visual designer support (which is a dealbreaker for many multidisciplinary teams).
As someone currently involved in switching our app from MFC, I really want to like MFC, but Microsoft's absolutely addled management of the whole thing is making it really difficult.
Nah, it is so bad, that on BUILD 2024, they have brought back first level status to WPF.
No one burned with WinRT history since Windows 8, is ever touching WinUI, unless they are Microsoft employees on WinDev, or companies with sunken costs trying to keep their products around.
Win UI 3 is the worst kind of improvement because there's arbitrary equivalence between WPF concepts and WinUI concepts, not a 1:1 equivalence. WPF as the mature stable model should be gospel; you don't re-write the gospel. Yet Microsoft feels they should re-write this gospel because... it aligns with the vision (???). Both use XAML, but the concept of DataContext is substantially changed, the concept of bindings is substantially changed, etc. Why make every XAML attribute ever-so-slightly different? Are those changes really an improvement? A lexical improvement? A performance improvement? Or just baggage and overhead to learn?
Compare Microsoft to OpenGL. Boromir says "one does not simply change the OpenGL API..." Microsoft does not have nor ever had OpenGL level of API with their UI frameworks. I guess you could say WPF is maturity in age only but doesn't represent conceptual maturity.
With the differences, you basically throw away all the knowledge of WPF to restart in WinUI, and with poor documentation. The documentation is there, i.e. the "what" but the docs should be primarily "the why and how"; how to map WPF concepts to WinUI3, which is arguably the more critical documentation to provide, and currently pitifully poorly documented.
Doubly so because it would help indicate a measure of feature equivalence; does WinUI 3 currently represent feature equivalence to WPF? Has XAML Behaviors been integrated as a member of the API?
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.
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 and fully skinnable/themable/l10n/i18n did add quite a bit which we hadn’t realized when thinking 150KB was realistic. But it’s not like we resorted to any crazy tricks; that was just the stripped linker output.
It was still a reasonable download at the dominant dial up internet at the time (28.8Kbps IIRC)
Sure, modern tools add a lot of cruft that you’d have to work hard to reduce, 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?
I actually used FLTK for the first iteration; The theming support it had at the time was not sufficient, though, and the i18n story non existent (that was before even 1.0, versions were still labeled by dates).
So, because pervasive theming/branding was a hard requirement, and i18n a softer one (every skin has to only support one locale), i had to abandon FLTK. But FLTK did spoil me by providing seamless flicker free double buffering out of the box, which I insisted on implementing in our gui.
For those of you who don’t remember - Win32 flickered badly on almost all screen updates, window resizes, etc — I think that was generally true of most apps until 2010 or so. FLTK was essentially the only GUI toolkit at the time (1999) that had no flicker out of the box.
IMO, every media player since Winamp 2.x has been largely a step _backwards_ in pretty much every metric one could put forth. It was light-weight, using minimal CPU & RAM. It was skinable. It was reliable. It had great plugin support. I don't recall it leaking memory, either. I basically had it set to auto run on login on my PC. I never closed it. Didn't need to. I had _only_ 32MB of RAM on that computer.
My app is around 500 KB (not megabytes) and it supports dark mode (see https://www.abareplace.com/). So this is definitely possible without using Electron or bloated GUI libraries.
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.
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.
Is this really still true though? VS Code and Slack are all quite polished and give me no issues as a user. Not sure what else I'd consider to build something similar.
I might understand polished, but no issues sounds odd. What about the abysmal performance?
Also most folks building things do not have the resources that Microsoft has, so I believe VSCode is not a good represantative of most Electron software.
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.
I've been eyeing https://neutralino.js.org/ since if I'm going to make the app render right on browsers then relying on the same code via webviews likely isn't (much) more portability effort.
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.
1GB for each app accumulates really quickly. 40MB is really low, but I wouldn’t be happy with 1GB per app personally. Anything below 500-600MB is fine.
I want my disk space for large medias, not for a desktop app
Not an expert, but could you use something like https://enigmaprotector.com/en/aboutvb.html to virtualize a file system to create a portable exe. Not sure if the size would exceed your specs.
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.
It MUST be open spec. It MUST be free for all/any to implement. It MUST either be included or be in the primary vendor (MS, Apple, distro) software center.
A simple Hello World, click OK to exit the program application should be able to be cross-compiled for any platform, and the resulting binary MUST NOT require including / embedding DLL / library hell like everything today does. It SHOULD be a small entirely dynamic program; possibly a few hundred kilobytes at most but even that seems too large. After all, it would mostly be the basic boilerplate of setting up memory, calling the system library loader, and linking in the shared libraries.
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.
In both OpenStep Enterprise and Yellow Box for Windows, while the UI elements still have some NeXT-isms, it's not terribly out of place, either.
However, this got scrapped sometime when Apple abandoned Rhapsody (which had PowerPC and x86 versions) in favor of Mac OS X (which was originally only available for PowerPC until the Intel switch in 2006, though Apple maintained an x86 version internally during the PowerPC years). During the transition from Rhapsody to Mac OS X, Yellow Box was renamed Cocoa.
The impetus here is that Adobe had initially promised a free, then low-cost license for Display PostScript --- when that was pulled, Apple had to come up with an alternative --- that and the fact that all the major app vendors announced that they weren't willing to do top--to-bottom re-writes using the NeXT frameworks (there was even a rumor that "Yellow Box" was named for the sake of Bill Gates' comment, "Develop for NeXTstep? I'll piss on it.")
So, Apple, led by Mike Paquette and many other talented folks from NeXT created Quartz (née Display PDF) and Carbon and instead of a consistent environment with a single API, we got an assemblage of technologies which had a Calculator app written in Java which took _forever_ to load, a Finder written in Carbon instead of Workplace.app, and icons cluttering the desktop and a Sidebar instead of a Shelf, and a bunch of Carbon apps.
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.
I wonder how possible it is to design a cross-platform GUI framework that not only uses the native UI widgets of each underlying platform, but also respects each platform's human interface guidelines. I'd imagine this would be very hard work, especially the part about respecting each platform's HIG, but the increased power of AI tools could potentially make this task easier. Such a framework could potentially be an appealing alternative to Electron for making cross-platform applications, with the benefit of conformity to each platform's HIG.
There have been many frameworks that offered this and some still do. But it comes at the direct expense of design discipline, branding, and user experience optimization -- all of which have been elevetated to high concern over the 15 years or so.
Cross-platform "Native look and feel" currently works for some no-nonsense professional utitlies and hobby tools, but mostly makes software that's hard to sell, document, or support.
Most have just opted for common widget libraries instead, and frameworks have stepped up by providing rich libraries of such widgets and prioritizing features for customizing or complementing them even further.
I’ve been thinking more lately about a library which defines an interface for GUI elements, and then leaves implementing that up to you. Something like MVC (or some other design pattern) where the view part is an interface definition.
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.
The library exists, BUT it is NOT shipped natively and NOT (AFAIK) something which trying to run a random downloaded utility app will trigger the system library loader prompting for the 'common wxWidgets runtime, for free, codesigned by Microsoft' download and install from the store to run the app.
> the resulting binary MUST NOT require including / embedding DLL / library hell like everything today does
If there's no DLL required then why does it matter if the DLL is automatically downloaded from the Microsoft store? DLLs are not useful for statically linked binaries.
> 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.
If anything is going to get copied by Linux as is... it'll be Win32 API so mono / C# stuff can bind directly to that, and Mac/OSX will be even more isolated.
For something to be portable everywhere it'll have to be an industry standard that the existing industry buys into.
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.
Unfortunately, if you are insisting on a single exe file, then you have to be way more flexible on your requirements than the author is. There’s a reason that practically every Windows program has an installer. It’s stupid and a waste of time but also probably more of a waste of time to try to be the exception to this rule.
Frankly I don’t see why C# targeting an old (3.5?) .NET framework version wouldn’t work for the author. There seems to be a tendency to fixate on how things should be vs where we are now. C++ native GUI dev is not a mainstay like it used to be.
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 should be quite possible to target .NET 3.5 and hit all the other requirements, except native C++. They hinted at this and then started talking about C++/CLI. If there’s ever a tool of last resort, that is it.
There are solutions if you're not hell-bent on using C++, be it .Net, Lazarus (FreePascal) or Delphi. We're using Delphi at work and for the most part it's super simple and easy.
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.
Indeed, QML and C++ together are the best mix out there for GUI development. I've written my block editor completely using Qt C++ & QML: https://www.get-plume.com/ and it was a breeze.
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.
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 platform. That lack of long-term support and consistency extends to a ton of areas in the Windows world, not just GUI development.
> 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.
Oddly AppKit seems to be one of the most stable desktop frameworks I have worked with. They've made breaking changes, sure, but they haven't been rewriting, and rewriting, and rewriting the same stuff for the last decade and a half.
The situation on Windows these days feels like... cognitive dissonance. If given a Windows app assignment today, I'd pick WinForms if less complicated, WPF if a larger project.
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#
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.
The problem with all of these technologies is that they were invented by different divisions of Microsoft to do different things. That, and Microsoft chasing the Next Big Thing.
What we consider to be "Win32 apps" are built with a framework in USER.dll, which is half reimplementation of the classic MacOS Toolbox API and half a pure-C object oriented class system. It's been here since the beginning, and is the lowest common denominator for getting anything on screen. Every other toolkit eventually opens a USER window, attaches the appropriate window class and wndprocs to it, and then yields CPU control to an event loop that, among other things, contains a Windows USER message pump.
USER, being an object-oriented, pure-C[0] API, is infamously verbose to work with. The "200 line Hello World" example everyone passed around back in the 90s is specifically that verbose because of all the bookkeeping you have to do for USER's sake. It is possible to build USER apps that work well, but it puts a lot of onus on the programmer. Even things like high-DPI support[1] or resizable windows are a pain in the ass because they all have to be implemented manually.
Microsoft's original answer for "USER is too hard" was to adopt Visual Basic or MFC as you mentioned. AFAIK .NET WinForms was also a wrapper around USER. This is why Windows had a cohesive visual appearance all the way through to Windows 7, because everything was just developer-friendly wrappers around common controls. Even third-party widget toolkits could incorporate those controls as subwindows as needed[2].
The problem with USER is that it was built for multiple windows and applications that render (using the CPU!) to a shared surface representing the final visible image. Modern toolkits instead have multiple separate surfaces and draw on them as needed before presenting a final image to a compositor that then mixes other windows together to get a final image. Windows Vista onward has the compositor, but the UI toolkits also need to be surface-aware instead of chucking a bunch of subwindows at DWM at the last minute.
WPF is the first attempt at a modern UI toolkit. Relative to USER resources are replaced with XAML and window classes replaced with... well, actual language classes. Except it was developed by the DevTools division (aka DevDiv), and only ran on .NET with managed code. If you had a native application or just didn't want to pay the cost of having a CLR VM, tough.
Then the iPhone launched. And the iPad launched. The thing is, good tablet UI needs GPU-acceleration up and down the stack, so Microsoft shat themselves, gave the Windows division (aka WinDiv) the keys to the castle, and they completely rewrote WPF in C++ with some fancy language projections. That became "Metro" in Windows 8, then "Modern UI" after a trademark dispute. Microsoft wanted Windows 8 to be a tablet OS, damn it, with full-screen only apps and no third-party app distribution.
And then most people just bought Surface tablets, opened the Desktop "app", and used the same USER apps they were used to, complaining about the Start Screen along the way. So Microsoft pivoted back to a normal desktop with Modern UI apps, which are now called UWP apps, and there's a whole bunch of new glue APIs to let you stick XAML subwindows inside of USER or just use UWP outside of AppX packages, which is what Windows 8 should have done, and now everything is just a mess. WinUI 3 is just an upgrade to the XAML library that UWP apps use, but it sounds like Yet Another Toolkit. MAUI is some kind of meta-toolkit like the old AWT on Java.
At some level, I can explain this, but it's not reasonable. There is no "native" UI toolkit or consistent look-and-feel on Windows anymore. I suspect this, more than anything else, is the reason why Windows killed Aero blur-behind everywhere, and why Electron apps are so damned popular now. HTML and CSS are almost as old as USER, but with consistent engineerin...
AppX packages got a bad rep as well for a couple of reasons. Lots of new footguns when dealing with them or trying to remove them for imaging / mass deployment scenarios.
The first introduction to AppX was often a metric load of crap on the machine - see below for a sample of the type of AppX stuff that was the first introduction to AppX for some folks which were often low effort marketing type stuff.
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.
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.
The solution you end up with will be a compromise on your requirements. E.g. if you can compromise on the 40MB size requirement then Electron should be a good fit to cover all your other requirements.
Unfortunely it is built on top of WinUI 3, with all the warts it entails.
Mostly because since they killed C++/CX, there is no UI tooling story for doing XAML C++, without having to deal with IDL COM like mess in Visual Studio, only worse in WinRT case.
> Unfortunely it is built on top of WinUI 3, with all the warts it entails.
I'm not sure that's relevant. The whole point of React Native is that you do not touch the underlying framework. Instead of churning out XAML, you just write React and let the framework bother with how the GUI is implemented under the hood.
I'm working on a GUI toolkit that should match the requirements: Slint - https://slint.dev
Can be compiled statically in a single .exe that is smaller than 40M. Has a license that allow proprietary on desktop for free. Has dark/light styles. Even comes with a (work in progress) drag and drop WYSISYG editor.
There must be some confusion. This is not a web framework, it is a compiled framework with API for several programming languages (including C++) and no HTML/CSS.
From https://news.ycombinator.com/newsguidelines.html: "Please don't comment on whether someone read an article. "Did you even read the article? It mentions that" can be shortened to "The article mentions that.""
I realize project != article but the same point applies.
Note that if by following that guideline, your comment gets "shortened" to the empty string, the implication would be not to post. More helpful, though, would be to supply some specific information.
I acknowledge your comment, and I'm aware of the guidelines. I'm not the only one who questioned their response, so I don't feel particularly off balance here.
Oh I'm not saying your underlying point was wrong or bad! It's a question of how you express it. If it pattern-matches to a snarky internet dismissal, that makes it a bad HN comment even if the point is right. That's because readers will react more to the pattern-match than anything else.
It's even more important to follow the guidelines when your point is right, because if you don't, then you give readers an extra reason (e.g. snarky dismissal) to discredit the truth (i.e. your correct point) and this is a bad deal for everyone. Past explanations in case helpful: https://hn.algolia.com/?dateRange=all&page=0&prefix=true&sor....
p.s. I don't think what you did was so bad and the length of my response here is just because I think you might find it interesting. It's not meant to pile on criticism.
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?
Man, as a C# dev, I'd kill for a single exe output. The binary being only 40MB is an absolute fantasy.
We have a project at work, it's nothing crazy, mostly shuffling data from one pipe to another, maybe a few thousand lines of code. A true standalone build including dotnet is over 180MB. The build that relies on the system dotnet install is still over 50MB. It's not even a GUI, it's a background service.
Things on Windows have a bad habit of enormous binary bloat, I'm not sure why. I don't think the problem is near as bad on Linux in general, but I don't have enough experience with linux dev to really say
I deploy my asp.net site to Linux by building it as a self contained single file. Deploy services. Have a couple of WPF apps both self contained single file.
They all end up around 43-85mb. The services are smaller when trimming is applied at around 30mb.
Not a single project has ended up over 100mb but I can see that happening if you have a ton of nuget packages.
I don't know for certain but expect it comes from comparing solutions with those based on virtual machines like Java's. The requirements in the original article look like a corporate wish list.
OP said less than 40MB. You can build Slint binaries targeting embedded devices. So a few hundred KB for a small application. Still arguably too much space but gui frameworks like slint use a domain specific language that generates more verbose code than what a human would typically write. Probably in the interests of being generic.
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'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.
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!
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.
Also the single exe deployment, while convenient at times, is perhaps not worth the hassle in this scenario. Using a packager like Velopack (squirrel) makes it a single exe to distribute and as an added bonus makes it self updating. That it has two or more files on disk when installed seems like a good tradeoff.
Windows is the worst platform to develop desktop apps for, apart from all the others.
> 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.
Some of the issue is he has outdated understanding of AppX packages (MSIX). You can use all of Win32 from an MSIX package, and all of WinRT, and WinUI3 etc. It's actually the other way around: there are some Win32 APIs that only work if your app is packaged.
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 “oh this doesn’t work in unpackaged apps” or “works in unpackaged apps but only in .NET Preview something-something”.
.NET 8 fixes a lot of this by adding AOT compilation and single-binary releases, but it’s still fairly large. .NET 9 then improves culling of unused framework code from your published file, and also adds WPF -> WinUI3 theming support.
Source: my repeated attempts to rewrite our product’s UI in WinUI3 (from WPF on .NET Framework 3.5) several times.
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 by enabling identical method folding in ILC, the worst offender used to be Kiota OpenAPI generator causing this, but thanks to tireless work by Filip Navara that was fixed there.
In general, there are quite a few knobs for configuring how exactly you would like to have your application published. This is also an area of active improvement with each new release as you noted. It is very worth it to look into further build configuration nonetheless. If you still face an issue with "this surely shouldn't take this much space", it might be a good idea to submit it to either https://github.com/dotnet/runtime or to the repo of the GUI framework depending on where you think the fault lies - without feedback it's difficult to know if there is an area that needs improvement or a known improvement opportunity that has demand.
Self-contained/single-file mode is compatible with trimming and benefits from the work done to improve AOT story. As AOT binaries get smaller and ILLink's analysis gets smarter, the single-file trimmed binaries will see a part of such improvements.
The issue is that many GUI frameworks are not AOT-incompatible per se but rather trim-incompatible as they rely on reflection that is done in a way that is totally opaque to ILLink save for rooting everything.
You can try the following publish option anyway, and in many instances it "just works" (assuming .NET 8 SDK):
dotnet publish -o out -p:PublishSingleFile=true -p:PublishTrimmed=true
Note: trimming was introduced in .NET 6, and NativeAOT was initially introduced in 7, so it had seen quite a bit of work to mature and improve by the time 8 shipped.
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.
I don't understand why Microsoft puts it on the user/dev to make sure their own dependencies and "VC redistributables" are installed.
Like shouldn't Windows 11 just either have that already or pull it down as needed as it's an official MS library.
Feel I always hit a roadblock when setting up a new PC where one of the things needs that but the dev didn't provide it and I have to get it myself. Which feels weird when it's an official MS thing from their official dev tools.
The app manifest could state "I need this runtime installed". The OS can know whether it is already installed or not. The OS also knows whether it is internet connected or not. If a runtime that isn't installed is needed and internet connectivity isn't available, the OS could state that, with information about how to procure the runtime manually.
That would stop people that have copied thr application from a pendrive in an air gapped system, that's true. One could make the case that someone meeting all of those requirements for would be technically minded enough to figure it out.
This wouldn't help developers who want to distribute a small application that won't ever require a download, but would be an improvement for anyone already distributing .Net applications over the web.
The OS presumably also knows where I should get it from as the same company hosts the installer as ships the OS. Yet IIRC the error is just an obtuse thing complaining a DLL isn't there and through googling and hopefully finding your way to Microsoft.com not some malware site you have to find the installer yourself.
Mild annoyance for someone with 28 years Windows experience, complete roadblock or malware vector for someone who just wants to use a computer rather than understand a computer.
Microsoft's solution to DLL hell was installing lots of DLLs side-by-side. The problem with WinUI and VC redistributables is that we've now got a combinatorial explosion of them and teaching an installer to know and understand the complex network of dependencies is a lot of work.
Microsoft's intended solution to this was to write one last Installer platform to try to rule them all. That's where AppX and MSIX installers came from. Unfortunately for us all, that Installer platform was synonymous with the Windows Store/Microsoft Store for just long enough that everyone assumes that is all that AppX/MSIX were intended to be. Today MSIX supports everything you want to do in a Win32 application, plus all the Dependency Fu of getting a WinUI application correctly installed. Just about the only left that you can't install directly in an MSIX is kernel-level drivers and even then there are options depending on your hardware vendor relationship with Microsoft.
The article dismisses MSIX packaging out of hand, but given it is still referred to as AppX packaging in the article, the author might not be aware of how much MSIX packaging has advanced in a bunch of years and still makes some assumptions of MSIX limitations based on early Store-intended AppX restrictions.
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.
> 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.
I don't think the author is talking about interop here, but rather the fact that GUI front-end code written in C++/CLI still ends up being managed rather than compiled to native code. I suppose the author insists on the front-end executable being nothing but a PE x86-64 binary without any runtime/GC embedded in it, pure native code.
But why even use C++ for the front end if it’s going to be .NET? Managed C++ is mostly useful as a shim, not as a platform language. It’s not really an alternative to C# on the .NET runtime but just some C++ extensions for interop with it.
If you make a WPF/WinForms frontend then that should be the exe entry point, and that would likely be managed. Then your business logic would be the auxiliary DLL (which can be embedded into the managed exe). There could be a layer of C++/CLI between these to layers (C# front end and native backend) because it would make the interop a bit easier than having to do C-style interop.
Actually I find it much easier to write C++/CLI, than getting right all P/Invoke marshaling, specially if COM is also part of the picture.
Also C++/CLI can also generate native code when specific code patters are used, that is why there are some compiler flags to disable it, and such assemblies are considered unsafe.
Same here. People are confused because the author gave two options:
1. Bundle the .dll as a resource into the app and make it extract it to some temporary folder, then use P/Invoke and call the compiled .dll from within the C#/.NET app.
2. Use C++/CLI.
And then a single "problem" paragraph that didn't make it clear which problems go with which approach.
It strikes me that having the C++ requirement is part of what makes this difficult. I'd like to have seen some reasoning why not to just use C#. Seems like it could have made some things easier, especially given the author's praise of XAML and acceptance of Visual Studio.
I'm not saying C# is better than C++, but just that choosing one over the other does have an impact.
> 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.
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 anyone who wrote Windows GUI apps back in the late 80s -> early 90s before RAD is a thing.
As a side note. I recently got a book about WinG game programming on Windows 3.X/95. I remember back in the day the game Fury3, a fascinating 3d flight shooter game, was developed in WinG. It could be an interesting archeology project to develop something serious with WinG, the predecessor of DirectX.
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. :)
Yeah that's probably what it was back in the day. I recalled games run pretty slowly on Windows before WinG came out. Fury3 looked pretty slick, even in today.
You could do pretty decent games using GDI as long as you just wanted to blit some sprites and were very much adhering to what GDI would give you. If I remember correctly, all the examples in the "GameSDK sampler CD-ROM" (the original name of DirectX 1.0) were in fact not done with GameSDK or even with WinG, but straight GDI.
I think it was better and easier to set up a DIB, treat it as a double buffer of sorts and only use GDI to BitBlt it to screen.
Don't ask me how you do that, though it probably would not take me too much to page that stuff back into my brain by looking at the Microsoft Win32 manuals. Maybe CreateDIBSection? I still remember my kernel32.dll, but not GDI or User.
Anyway, what WinG did (and all it did) was speeding up the blitting part.
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?
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.
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++.
Wow that looks pretty slick. Now I know why early Windows don't have competitive games and why things like WinG and DirectX are pretty big. I think Carmack did not jump on the DirectX wagon until much later.
> 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).
It's called "Dungeons of Discovery". The book includes a CD with resources to build a mini yet full blobber game. The CD also contains WinG.dll conveniently.
576 comments
[ 2.7 ms ] story [ 425 ms ] threadGo back in an emulator some time and try Visual Studio or even old Borland from the 1990s. Point, click, add code, set style, and the result was not bad at all. The whole UI looked consistent too with uniform controls, shortcuts, etc.
Today UI apps use 100X more memory, are slower, and are harder to use with little to show for it in terms of improved functionality. The whole desktop is a disaster of conflicting designs and accessibility or uniformity are practically gone.
Mobile is kind of shocking too. Here was a chance to dump cruft from desktop and do things better but the result really is just as much of a pain in the arse if not more. Consistency is a little better but the developer experience is awful and of course unlike desktop you really can’t develop on the actual device. That adds another layer of shit.
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.
Absolutely, but I would go even further with this. I can't prove it, but I would bet a lot of money that Windows 10+ has made using a spinning disk even slower. I would guess optimizations around disk access were entirely different in the XP era compared to now, when it is assumed everyone has an SSD.
Anyway, I had an old laptop that ran like absolutely dog shit. I put an SSD into it and it magically became usable again.
Many thanks for hunting me down in some comments!
What does this have to do with bloated GUIs?
> 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.
I remember 98/XP running circles on mechanical harddrives compared to modern PCs on ultra fast SSDs. The fact that despite thousand times faster hardware we have slower performance is disgusting.
> If you don’t think modern apps have more functionality, I don’t know what to tell you.
Care to provide an example what modern applications have that older ones lack? Except for always—on connection and artificial bullshit imposed by modern OSs.
Then they shit canned everything for Xaml around the same time the whole industry abandoned any kind of WYSIWYG or rapid development technology.
Is anything stopping the author from buying a heat pump?
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
Generally anything you do indoor that falls under normal usage(painting walls, hanging furniture with big screws,etc.) is ok without approval, at least in my country/city(austria) and the land lord can't deny any of this and is not even required to be notified.
As you would have an open window and a not so noise machine running this would be ok, but energy efficiency is quite bad and you lose the benefits of the thermal insulation of your building.
Doesn't help that in new construction outer walls are usually very well insulated, and inner walls and floors aren't (by design; 70% of total heating cost is evenly split too), so you're working against your neighbors too. We have some stupidly complex building standards often driven by industry lobbying (which also makes building expensive), but installing a mini split hasn't made it on the list.
The only thing one needs is a window-sized cardboard with a round hole and blanket if your target room has no door. I just looked at prices and 10000BTU seemed to be ~350 euros.
The real reason most of us don't have AC is because it's hot for a very short period. Last year it definitely wasn't too hot for me to warrant having one. This year so far, it was, for a week: we had about 30°C (86°F) last week, but next week my mobile phone promises it's gonna be 20°C (68°F) maximum, which does not need AC. Maybe that will change, though.
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.
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".
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.
MSYS2: https://www.msys2.org
Meson: https://mesonbuild.com
The problem about Windows is, that Microsoft adds new APIs repeatingly and doesn’t care much about the previous ones. While on Linux we’ve Gtk1, Gtk2, Gtk3 and Gtk4.
And while people complain about deprecations and changes they actually mean „API changes require work to use the new major. But these people keep maintaining it. And provide upgrade paths to enhanced versions? I’m in!“.
HiDPI, Wayland, new Widgets, new renderers and a scene-graph.
PS: If you need to keep it small and simple and address professional (power) users I suggest a TUI with the venerable ncurses. Or notcurses.
Notcurses: https://github.com/dankamongmen/notcurses.
Demo of Ncurses (For the lulz): https://www.youtube.com/watch?v=dcjkezf1ARY
+ "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, portable => small, simple application where functionality is more important than dark mode or other styling ability.
https://github.com/gammasoft71/Examples_FLTK/blob/c6f630eaa3...
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?
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.
No designer, manualy editing IDL files for XAML C++ bindings, without any kind of syntax highlighting or code completion, manually merging generated C++ code, even more lovely.
Using a Webview wrapping Bing Maps, instead of the native UWP map control, even better.
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.
The net effect is that not only are they not capable of building things as well as they used to, they can’t even maintain what they already have. And how would anyone go about fixing such a culture. I think that’s a big part of why MS has been so generous to OpenAI while also keeping them at arms length.
Inertia is incredibly powerful and big companies can remain successful for long after their technical competence dissipates.
I'm not sure where you got that impression, but WinUI3 is in almost all of Microsoft's software at this point. Admittedly a huge amount of it is embedded inside React Native, but WinUI3 seems to be the UI toolkit that has won and is still going strong. They announced a bunch of WinUI3 enhancements at BUILD even.
(One such announcement is a coming standard control for the sort of custom Windows Title Bar with a search box and branded logo and extra buttons that has become common in every first-party application from the Microsoft Store app to all of Office and many other places.)
> Contrary to this article, it still doesn't even have a visual designer.
Huh? Visual Studio has a visual designer for the WinUI 3 flavor of XAML. If you don't want to write XAML to back your UI they probably will never support a Visual Designer for you (ie, C# UI seems neat and maybe a bit more "functional programming", but I'd rather use XAML just to have the Visual Designer at least). Last I checked the XAML designer works just fine even in C++ projects targeting WinUI 3.
[1] - https://github.com/microsoft/microsoft-ui-xaml/issues/5917
Relatedly, I still think it is something of a shame that (Expression) Blend didn't survive to the modern era. A designer-focused XAML design tool that doesn't need a full Visual Studio install (nor the same sort of expensive VS license) and feels more like Firefly or Figma or whatever other designer-focused tool is current en vogue would be really handy in a lot of situations.
I don't think it is the only reason that designers tend to prefer HTML (and thus we use Electron or similar to placate the designers that think that "just copy and paste it from the design tool" works "well") over XAML, but it certainly doesn't help that there isn't a "XAML Figma" and it's a shame on multiple levels that Microsoft recognized that threat early on, built a solution, then got confused why they built it, confusingly merged it into Visual Studio licenses and installs, which lead to its sadly inevitable death just a few years before it would have been very helpful to have to send to some designers and stop getting HTML-only mockups.
I almost feel like you're mixing up WinUI 2 and 3, because the designer was kind of borky for WinUI 2 but did work, and was overall an okayish experience. But for WinUI 3 it's an entirely different game. Early on the messaging was that the designer would be "coming soon" (tm) and that people could just use hot reload in the interim, then at some point hot reload ended up completely broken as well, Microsoft gradually started withdrawing engagement with the community, and here I am saying it's been defacto abandoned.
The point of the designer is not just mock ups. At many (most?) small businesses and studios the developer/designer dichotomy doesn't exist. There's a reason lots of companies are still even using e.g. Winforms. A high functioning designer simply dramatically improves both productivity and quality.
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.
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.
I’ll get shot for this one but I write most of my GUIs in Excel these days.
You should be proud like that.
Less useful these days as we use open formats, ie doc is propriatery, docx is open
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.
How do you manage a 15 million LOC desktop app originating from the late 90s which contains chunks of win32 native, ATL, MFC, custom GDI+ wrappers all sorts?
Aye you fuck off and work somewhere else that's what you do. Which is why it's still written in win32 native, ATL, MFC, custom GDI+ wrappers.
They paid two companies to come in and rewrite it, first in Qt which was a complete failure. Then in Electron etc, which was also a failure.
You're complaining about your personal legacy "chunks of win32 native, ATL, MFC, custom GDI+ wrappers".
Not C++. Just your personal legacy projects you didn't managed to maintain or update.
C++ doesn't magically rewrite your technical debt. You need to do your work.
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 40MB limit also rule out a lot of options. The author admits that Qt could have met these requirements but the open-source licensing part wasn’t compatible with his goals and he didn’t want to pay for a license.
If you relax the requirements to tolerate some dependencies, allow larger download sizes, or to simply use built-in Windows GUI controls the situation is very different.
For writing a lightweight, completely custom GUI with no external dependencies and permissive licensing I could have guessed ImGui would be the answer before I started reading.
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.
In that case, any Qt fork would force him to also comply with the GPL, and supply the source code of his project.
It's not a problem.
The LGPL is working as intended.
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 normal static linking, it's only a bit harder. 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?
> or distribute object files for recompilation
Do you need to ship it alongside or produce it on request or link to where they can fetch it? It's not like you need to ship source code alongside either for GPL binaries.
Does this also mean that one could put most of the closed source part into a DLL, make a shell executable that is open source and statically link LGPL code into the latter? This then would allow modifications to the LGPL code to be put in just by having the closed source DLL.
I am not a lawyer.
You might even be able to use partial linking (ld -r) to ship a single .o file instead of a bunch of them.
But yeah at least a few of those caveats remain. Although keyboard navigation and font rendering have quite a bit of support.
Comparing this to (something like) WPF, you create XAML files, with either or combination of ViewModels and back-end code to "bind" and can get complicated quickly. I guess the only exception to this is if you have commited to WPF non-stop for many months. However, with IM interfaces, its easy to get going (imo)
It often isn't a secret: https://github.com/ocornut/imgui/wiki/Software-using-dear-im...
[0] https://github.com/tildearrow/furnace
[1] https://github.com/superctr/mmlgui
[2] https://x.com/yuzokoshiro/status/1800554520256360794
- French Keyboard and Backend SDL2 - Several keys are not checkable with IsKeyDown
- Wrong ImGuiKey keydown indexes reported from Win32 backend for some keys when using UK keyboard with UK keyboard layout
There are also 2 issues with IME:
- Marked Text / SDL_TEXTEDITING Event / IME Composition support
- Backspace handling by text widget in default Windows IME environment.
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.
There are exceptions, for very rich dense UI, for UIs that need to be cross-platform, but if you're writing a Windows app, it should look and feel like a Windows app.
Even Microsoft struggles with that.
That’s not exceptional at all. That’s completely normal requirements that are probably in the majority.
Does Microsoft themselves build their apps this way?
You need consistency in the icons, layouts and concepts, but you don't need every widget to look exactly the same on every platform.
With the exception of games try to use the native GUI. It’s the best choice most of the time.
Is your app as large and important as the OS of the device (Chrome/facebook/etc...) you should probably have similar language across devices.
Is your app very large but not that large? (Slack/teams come to mind) I think you can go either way.
If you are smaller than that (hint: you are) then you should comply with the design language of the platform, even if that means somewhat large changes such as moving buttons from the left to the right. The likelihood that users are constantly using your app on a iphone and android is really low.
I’d still like to see them try to match a little, but they’re specialized enough I get that may be a better path.
Chrome? Facebook? Slack? Teams? No.
I’m not saying things need to look like MyFirstWin32App built with VB6 in 20 minutes.
But use the system controls and conventions. Custom colors and layouts can be fine. But if you want to make your own UI toolkit then make your own OS too and leave my computer alone.
No app is more important than the OS, and certainly not Facebook (which has no business being an app in the first place). I made a choice when I got the OS, and I like developers respecting it and not chase the fad of the day with poor approximations of the native widgets (text fields that do not support standard shortcuts, buttons that do not behave as they should, labels that do not support accessibility features, the list could go on). Even huge apps like Photoshop or Office get this wrong everywhere.
I definitely agree on the default (use the native toolkit), but there are no applications big enough to get their own behaviour. Open Source or hobby applications get a pass if the UI is a bit wonky, but that’s about it.
I'm not sure anyone could really answer this question considering how fast Microsoft's various silos pinball between UI conventions. All of them are (I would hope) based on various iterations of their own internal tooling, but looking from Windows 7 to 8, 10, and then 11, you get such stark differences in UI language that you feel like you're looking at competing products.
That being said, I would personally very much prefer apps that are built to mimic the system they are a part of. One of the worst sins of that one, IMO, being iTunes on Windows which has always been and continues to be a flaming dumpster fire for a number of reasons, but most especially it's UI. It is a Mac app that is parked in Windows. It looks like a Mac app, it operates like a Mac app, it's UI conventions are that of the Mac, with the one major difference being they stuffed the window controls in the window in an incredibly slapdash way to account for Windows not having the system bar.
But yeah, for any marketing people here, I have not once nor will I ever give a single molecule of a shit about your brand identity. Make your software good. Ideally make it mesh with the system it's in. I couldn't fucking care less what color everything is.
Gone are the days of my friend accidentally having his volume cranked when he inserted the Red Alert 2 disc, not knowing it would blast out "WARINING! Military Software Detected!"
The documentation was absolutely maddening.. Half the time the Apple docs referred to a previous version. “Do this thing in XCode” often included screenshots of UIs that don’t exist in the current version of XCode. Examples I found on Stackoverflow or random blogs were usually no longer applicable.
It felt like magic when it worked, all those VStack HStack nestings, but the annoyance of finding my way there made me seriously doubt whether I’d build a big app with SwifUI, especially if I wasn’t working alone.
EDIT
From your experience, what GUI toolkit would you prefer? And, it would help to know what is your target UI platform.Today I was making a list of reasons/excuses for using Material Design on Mac… which I guess would make some people mad, but it might work for an enterprise product.
That said I did do a fair bit of my own theming. The Flutter Material widgets are actually pretty customizable and I'm not a big fan of vanilla Material.
https://plastaq.com/minimoon
I’m not in a position to give anyone advice, but I’d love to find SwiftUI but cross-platform and usable from anything other than XCode (well maybe not Ed…) and native GUI and a pony.
For my product I need to support Mac, Windows and eventually iOS/iPadOS. For prototypes iOS is enough. I don’t mind learning new languages for this, but ideally there would be some advantage in knowing the language itself. I’ve been looking at lots of frameworks over the past month.
The most tempting thing so far is Flutter, but I have nagging doubts: because it’s not native UI, I worry about that being a no-go for some large customer down the road, and also about alienating power users. I looked at React Native but it’s not very good for desktop yet as far as I could tell (and the demo app from the documentation doesn’t work, which is a bad sign). Which is too bad because I was impressed with Expo, if I just needed phones I’d probably use that. I looked at Avalonia but it has the opposite problem.
Today I’m looking at Tauri for the Nth time: at least I could improve my Rust, and it seems to have momentum. Doing the UI in a web view is kinda sad, though, after trying SwiftUI.
Just building multiple apps is not realistic, I’m a solo dev and want to get this to market in my lifetime, and it only makes sense if I have both Mac and Windows.
Very happy to hear recommendations from people who have done this!
I'm not convinced many users care that much about this though. They spend most of their day using apps that don't use native controls and I think they're all pretty used to it by now.
I prototyped a bunch of different desktop toolkits and I think that today Flutter is by far the most polished and mature. I've had overall a very positive experience using it for my music app:
https://plastaq.com/minimoon
The threat of Google canceling it is real though. I suppose if that happens I'll switch to Tauri or just give up on Windows and Android and do SwiftUI. My experiences with SwiftUI to this point have not been very positive though.
Kotlin Multiplatform might also be an option at some point but it doesn't seem that close today. Unfortunately it seems like none of the os vendors are making their desktop APIs a priority these days.
Yeah the Google risk... seems like they came out strong in support of Flutter at their last dev conference, but at the same time it does _not_ look like they're using it for their main apps.
And yes I’d feel more confident in Flutter if Google was dogfooding it a lot more.
Edit: and fully static linking. Might be a meg or so.
Do you need to ship any supporting files separately, along with the app?
And is .NET 4.8 or higher already on Windows PCs?
With .NET 9 right around the corner, how far behind the legacy stack is only increases.
.NET > 5 will never be installed out of the box on Windows PCs. The trade offs to that concession however are: cross-platform support, better container support, easier side-by-side installs support ("portable" installs). .NET > 7 can do an admirable job AOT compiling single-file applications. For a GUI app you probably aren't going to easily get that single-file < 40MBs yet today, but it's going to be truly self-contained and generally don't need a lot of specific OSes or things installed at the OS level. Each recent version of .NET has been working to improve its single-file publishing and there may be advances to come.
Microsoft have utterly screwed the pooch on getting their .NET GUI story straight.
As someone currently involved in switching our app from MFC, I really want to like MFC, but Microsoft's absolutely addled management of the whole thing is making it really difficult.
No one burned with WinRT history since Windows 8, is ever touching WinUI, unless they are Microsoft employees on WinDev, or companies with sunken costs trying to keep their products around.
Compare Microsoft to OpenGL. Boromir says "one does not simply change the OpenGL API..." Microsoft does not have nor ever had OpenGL level of API with their UI frameworks. I guess you could say WPF is maturity in age only but doesn't represent conceptual maturity.
With the differences, you basically throw away all the knowledge of WPF to restart in WinUI, and with poor documentation. The documentation is there, i.e. the "what" but the docs should be primarily "the why and how"; how to map WPF concepts to WinUI3, which is arguably the more critical documentation to provide, and currently pitifully poorly documented.
Doubly so because it would help indicate a measure of feature equivalence; does WinUI 3 currently represent feature equivalence to WPF? Has XAML Behaviors been integrated as a member of the API?
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 and fully skinnable/themable/l10n/i18n did add quite a bit which we hadn’t realized when thinking 150KB was realistic. But it’s not like we resorted to any crazy tricks; that was just the stripped linker output.
It was still a reasonable download at the dominant dial up internet at the time (28.8Kbps IIRC)
Sure, modern tools add a lot of cruft that you’d have to work hard to reduce, 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?
So, because pervasive theming/branding was a hard requirement, and i18n a softer one (every skin has to only support one locale), i had to abandon FLTK. But FLTK did spoil me by providing seamless flicker free double buffering out of the box, which I insisted on implementing in our gui.
For those of you who don’t remember - Win32 flickered badly on almost all screen updates, window resizes, etc — I think that was generally true of most apps until 2010 or so. FLTK was essentially the only GUI toolkit at the time (1999) that had no flicker out of the box.
Given that it’s windows, it might still run today, so it likely is still possible
I still use Winamp, and essentially in its 2.x mode.
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'd add "for free because I'm too cheap to buy a license for a toolkit that does what I want".
fact that you must ship the app Unpackaged is particularly strange.
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.
Is this really still true though? VS Code and Slack are all quite polished and give me no issues as a user. Not sure what else I'd consider to build something similar.
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.
I want my disk space for large medias, not for a desktop app
It MUST be open spec. It MUST be free for all/any to implement. It MUST either be included or be in the primary vendor (MS, Apple, distro) software center.
A simple Hello World, click OK to exit the program application should be able to be cross-compiled for any platform, and the resulting binary MUST NOT require including / embedding DLL / library hell like everything today does. It SHOULD be a small entirely dynamic program; possibly a few hundred kilobytes at most but even that seems too large. After all, it would mostly be the basic boilerplate of setting up memory, calling the system library loader, and linking in the shared libraries.
https://forum.winworldpc.com/discussion/11422/openstep-for-w...
It even survived Apple's purchase of NeXT, where the OpenStep API was renamed Yellow Box. There was a port of Yellow Box to Windows:
https://www.betaarchive.com/forum/viewtopic.php?t=29049
In both OpenStep Enterprise and Yellow Box for Windows, while the UI elements still have some NeXT-isms, it's not terribly out of place, either.
However, this got scrapped sometime when Apple abandoned Rhapsody (which had PowerPC and x86 versions) in favor of Mac OS X (which was originally only available for PowerPC until the Intel switch in 2006, though Apple maintained an x86 version internally during the PowerPC years). During the transition from Rhapsody to Mac OS X, Yellow Box was renamed Cocoa.
So, Apple, led by Mike Paquette and many other talented folks from NeXT created Quartz (née Display PDF) and Carbon and instead of a consistent environment with a single API, we got an assemblage of technologies which had a Calculator app written in Java which took _forever_ to load, a Finder written in Carbon instead of Workplace.app, and icons cluttering the desktop and a Sidebar instead of a Shelf, and a bunch of Carbon apps.
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.
Cross-platform "Native look and feel" currently works for some no-nonsense professional utitlies and hobby tools, but mostly makes software that's hard to sell, document, or support.
Most have just opted for common widget libraries instead, and frameworks have stepped up by providing rich libraries of such widgets and prioritizing features for customizing or complementing them even further.
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...
> the resulting binary MUST NOT require including / embedding DLL / library hell like everything today does
If there's no DLL required then why does it matter if the DLL is automatically downloaded from the Microsoft store? DLLs are not useful for statically linked binaries.
Win32 Hello World messagebox is a few hundred bytes.
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.
For something to be portable everywhere it'll have to be an industry standard that the existing industry buys into.
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.
Frankly I don’t see why C# targeting an old (3.5?) .NET framework version wouldn’t work for the author. There seems to be a tendency to fixate on how things should be vs where we are now. C++ native GUI dev is not a mainstay like it used to be.
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?
There, fixed it for ya.
There are solutions if you're not hell-bent on using C++, be it .Net, Lazarus (FreePascal) or Delphi. We're using Delphi at work and for the most part it's super simple and easy.
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.
But fair enough, it's quite good. If I had to write a C++ UI application, it'd be on my shortlist.
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 platform. That lack of long-term support and consistency extends to a ton of areas in the Windows world, not just GUI development.
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.
I think UIKit and SwiftUI (and to a lesser extent Appkit) are great
The situation on Windows these days feels like... cognitive dissonance. If given a Windows app assignment today, I'd pick WinForms if less complicated, WPF if a larger project.
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.
Remember when Microsoft honestly thought they had a shot at making a mobile platform to compete with Android and Apple?
What we consider to be "Win32 apps" are built with a framework in USER.dll, which is half reimplementation of the classic MacOS Toolbox API and half a pure-C object oriented class system. It's been here since the beginning, and is the lowest common denominator for getting anything on screen. Every other toolkit eventually opens a USER window, attaches the appropriate window class and wndprocs to it, and then yields CPU control to an event loop that, among other things, contains a Windows USER message pump.
USER, being an object-oriented, pure-C[0] API, is infamously verbose to work with. The "200 line Hello World" example everyone passed around back in the 90s is specifically that verbose because of all the bookkeeping you have to do for USER's sake. It is possible to build USER apps that work well, but it puts a lot of onus on the programmer. Even things like high-DPI support[1] or resizable windows are a pain in the ass because they all have to be implemented manually.
Microsoft's original answer for "USER is too hard" was to adopt Visual Basic or MFC as you mentioned. AFAIK .NET WinForms was also a wrapper around USER. This is why Windows had a cohesive visual appearance all the way through to Windows 7, because everything was just developer-friendly wrappers around common controls. Even third-party widget toolkits could incorporate those controls as subwindows as needed[2].
The problem with USER is that it was built for multiple windows and applications that render (using the CPU!) to a shared surface representing the final visible image. Modern toolkits instead have multiple separate surfaces and draw on them as needed before presenting a final image to a compositor that then mixes other windows together to get a final image. Windows Vista onward has the compositor, but the UI toolkits also need to be surface-aware instead of chucking a bunch of subwindows at DWM at the last minute.
WPF is the first attempt at a modern UI toolkit. Relative to USER resources are replaced with XAML and window classes replaced with... well, actual language classes. Except it was developed by the DevTools division (aka DevDiv), and only ran on .NET with managed code. If you had a native application or just didn't want to pay the cost of having a CLR VM, tough.
Then the iPhone launched. And the iPad launched. The thing is, good tablet UI needs GPU-acceleration up and down the stack, so Microsoft shat themselves, gave the Windows division (aka WinDiv) the keys to the castle, and they completely rewrote WPF in C++ with some fancy language projections. That became "Metro" in Windows 8, then "Modern UI" after a trademark dispute. Microsoft wanted Windows 8 to be a tablet OS, damn it, with full-screen only apps and no third-party app distribution.
And then most people just bought Surface tablets, opened the Desktop "app", and used the same USER apps they were used to, complaining about the Start Screen along the way. So Microsoft pivoted back to a normal desktop with Modern UI apps, which are now called UWP apps, and there's a whole bunch of new glue APIs to let you stick XAML subwindows inside of USER or just use UWP outside of AppX packages, which is what Windows 8 should have done, and now everything is just a mess. WinUI 3 is just an upgrade to the XAML library that UWP apps use, but it sounds like Yet Another Toolkit. MAUI is some kind of meta-toolkit like the old AWT on Java.
At some level, I can explain this, but it's not reasonable. There is no "native" UI toolkit or consistent look-and-feel on Windows anymore. I suspect this, more than anything else, is the reason why Windows killed Aero blur-behind everywhere, and why Electron apps are so damned popular now. HTML and CSS are almost as old as USER, but with consistent engineerin...
AppX packages got a bad rep as well for a couple of reasons. Lots of new footguns when dealing with them or trying to remove them for imaging / mass deployment scenarios.
The first introduction to AppX was often a metric load of crap on the machine - see below for a sample of the type of AppX stuff that was the first introduction to AppX for some folks which were often low effort marketing type stuff.
Get Skype: Get-AppxPackage -allusers skypeapp | Remove-AppxPackage Get-AppxPackage -allusers zunemusic | Remove-AppxPackage Get-AppxPackage -allusers maps | Remove-AppxPackage Get-AppxPackage -allusers solitairecollection | Remove-AppxPackage Get-AppxPackage -allusers bingfinance | Remove-AppxPackage Get-AppxPackage -allusers zunevideo | Remove-AppxPackage Get-AppxPackage -allusers bingnews | Remove-AppxPackage Get-AppxPackage -allusers people | Remove-AppxPackage Get-AppxPackage -allusers windowsphone | Remove-AppxPackage Get-AppxPackage -allusers bingsports | Remove-AppxPackage Get-AppxPackage -allusers messaging | Remove-AppxPackage Get-AppxPackage -allusers connect | Remove-AppxPackage Get-AppxPackage -allusers contactsupport | Remove-AppxPackage Get-AppxPackage -allusers feedbackhub | Remove-AppxPackage etc...
https://youtu.be/-NJDxf4XwlQ
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.
Microsoft has developed VSCode with Electron.
https://www.electronjs.org/
Microsoft also supports React Native, which is arguably way better than any webview-based approach.
Mostly because since they killed C++/CX, there is no UI tooling story for doing XAML C++, without having to deal with IDL COM like mess in Visual Studio, only worse in WinRT case.
I'm not sure that's relevant. The whole point of React Native is that you do not touch the underlying framework. Instead of churning out XAML, you just write React and let the framework bother with how the GUI is implemented under the hood.
Sadly the same applies to Lazarus/LCL too. Not only that, I had a nasty surprise recently when Fedora Budgie did not install GTK2 by default.
Win32 era was fun, for development and for reversing. But alas...
I realize project != article but the same point applies.
Note that if by following that guideline, your comment gets "shortened" to the empty string, the implication would be not to post. More helpful, though, would be to supply some specific information.
I acknowledge your comment, and I'm aware of the guidelines. I'm not the only one who questioned their response, so I don't feel particularly off balance here.
It's even more important to follow the guidelines when your point is right, because if you don't, then you give readers an extra reason (e.g. snarky dismissal) to discredit the truth (i.e. your correct point) and this is a bad deal for everyone. Past explanations in case helpful: https://hn.algolia.com/?dateRange=all&page=0&prefix=true&sor....
p.s. I don't think what you did was so bad and the length of my response here is just because I think you might find it interesting. It's not meant to pile on criticism.
That's... quite a high bar. Last I checked even a QML app was only like 20 MB. Why so big?
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?
We have a project at work, it's nothing crazy, mostly shuffling data from one pipe to another, maybe a few thousand lines of code. A true standalone build including dotnet is over 180MB. The build that relies on the system dotnet install is still over 50MB. It's not even a GUI, it's a background service.
Things on Windows have a bad habit of enormous binary bloat, I'm not sure why. I don't think the problem is near as bad on Linux in general, but I don't have enough experience with linux dev to really say
- https://learn.microsoft.com/en-us/dotnet/core/deploying/sing...
- https://learn.microsoft.com/en-us/dotnet/core/deploying/trim...
Alternatively, you could try the following first (use .NET 8 SDK):
Also, I just tried worker template (it includes generic host, DI, logger, etc.) and it's only 5 MiB when AOT compiled on macOS: Will likely take less on Windows and Linux.I deploy my asp.net site to Linux by building it as a self contained single file. Deploy services. Have a couple of WPF apps both self contained single file.
They all end up around 43-85mb. The services are smaller when trimming is applied at around 30mb.
Not a single project has ended up over 100mb but I can see that happening if you have a ton of nuget packages.
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.
Also the single exe deployment, while convenient at times, is perhaps not worth the hassle in this scenario. Using a packager like Velopack (squirrel) makes it a single exe to distribute and as an added bonus makes it self updating. That it has two or more files on disk when installed seems like a good tradeoff.
Windows is the worst platform to develop desktop apps for, apart from all the others.
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.
It is still years away to provide feature parity with UWP/WinUI 2.0, let alone the Windows Forms, WPF capabilites and Visual Studio tooling.
Using it from C++ is only for ATL / VisuaL C++ 6.0 die hards.
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 “oh this doesn’t work in unpackaged apps” or “works in unpackaged apps but only in .NET Preview something-something”.
.NET 8 fixes a lot of this by adding AOT compilation and single-binary releases, but it’s still fairly large. .NET 9 then improves culling of unused framework code from your published file, and also adds WPF -> WinUI3 theming support.
Source: my repeated attempts to rewrite our product’s UI in WinUI3 (from WPF on .NET Framework 3.5) several times.
In general, there are quite a few knobs for configuring how exactly you would like to have your application published. This is also an area of active improvement with each new release as you noted. It is very worth it to look into further build configuration nonetheless. If you still face an issue with "this surely shouldn't take this much space", it might be a good idea to submit it to either https://github.com/dotnet/runtime or to the repo of the GUI framework depending on where you think the fault lies - without feedback it's difficult to know if there is an area that needs improvement or a known improvement opportunity that has demand.
And that’s when you use “selfcontained mode” rather than AOT publishing, now with AOT it’s considerably better.
The issue is that many GUI frameworks are not AOT-incompatible per se but rather trim-incompatible as they rely on reflection that is done in a way that is totally opaque to ILLink save for rooting everything.
You can try the following publish option anyway, and in many instances it "just works" (assuming .NET 8 SDK):
Note: trimming was introduced in .NET 6, and NativeAOT was initially introduced in 7, so it had seen quite a bit of work to mature and improve by the time 8 shipped.And then there is the whole C# / C++ interop between CsWinRT and C++/WinRT.
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.
Like shouldn't Windows 11 just either have that already or pull it down as needed as it's an official MS library.
Feel I always hit a roadblock when setting up a new PC where one of the things needs that but the dev didn't provide it and I have to get it myself. Which feels weird when it's an official MS thing from their official dev tools.
In this day and age of everything always connected, some things still aren't always connected.
That would stop people that have copied thr application from a pendrive in an air gapped system, that's true. One could make the case that someone meeting all of those requirements for would be technically minded enough to figure it out.
This wouldn't help developers who want to distribute a small application that won't ever require a download, but would be an improvement for anyone already distributing .Net applications over the web.
Mild annoyance for someone with 28 years Windows experience, complete roadblock or malware vector for someone who just wants to use a computer rather than understand a computer.
Microsoft's intended solution to this was to write one last Installer platform to try to rule them all. That's where AppX and MSIX installers came from. Unfortunately for us all, that Installer platform was synonymous with the Windows Store/Microsoft Store for just long enough that everyone assumes that is all that AppX/MSIX were intended to be. Today MSIX supports everything you want to do in a Win32 application, plus all the Dependency Fu of getting a WinUI application correctly installed. Just about the only left that you can't install directly in an MSIX is kernel-level drivers and even then there are options depending on your hardware vendor relationship with Microsoft.
The article dismisses MSIX packaging out of hand, but given it is still referred to as AppX packaging in the article, the author might not be aware of how much MSIX packaging has advanced in a bunch of years and still makes some assumptions of MSIX limitations based on early Store-intended AppX restrictions.
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.
I don't think the author is talking about interop here, but rather the fact that GUI front-end code written in C++/CLI still ends up being managed rather than compiled to native code. I suppose the author insists on the front-end executable being nothing but a PE x86-64 binary without any runtime/GC embedded in it, pure native code.
If you’re writing C++ code running on .NET / .NET Framework, you’re basically writing masochistic C#.
If you make a WPF/WinForms frontend then that should be the exe entry point, and that would likely be managed. Then your business logic would be the auxiliary DLL (which can be embedded into the managed exe). There could be a layer of C++/CLI between these to layers (C# front end and native backend) because it would make the interop a bit easier than having to do C-style interop.
Because the author of the article wanted to use C++, I don’t know why. That’s why I called it “masochistic C#”.
Also C++/CLI can also generate native code when specific code patters are used, that is why there are some compiler flags to disable it, and such assemblies are considered unsafe.
I'm not saying C# is better than C++, but just that choosing one over the other does have an impact.
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.
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.
As a side note. I recently got a book about WinG game programming on Windows 3.X/95. I remember back in the day the game Fury3, a fascinating 3d flight shooter game, was developed in WinG. It could be an interesting archeology project to develop something serious with WinG, the predecessor of DirectX.
You could do pretty decent games using GDI as long as you just wanted to blit some sprites and were very much adhering to what GDI would give you. If I remember correctly, all the examples in the "GameSDK sampler CD-ROM" (the original name of DirectX 1.0) were in fact not done with GameSDK or even with WinG, but straight GDI.
Don't ask me how you do that, though it probably would not take me too much to page that stuff back into my brain by looking at the Microsoft Win32 manuals. Maybe CreateDIBSection? I still remember my kernel32.dll, but not GDI or User.
Anyway, what WinG did (and all it did) was speeding up the blitting part.
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?
For the string it's mostly the wchar and char stuffs. I think I'm getting a hang of it.
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++.
However by DirectX 10, he was also not happy with OpenGL mess, and changed his mind on DirectX.
https://www.bit-tech.net/news/gaming/pc/carmack-directx-bett...
> 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).
https://devblogs.microsoft.com/oldnewthing/20030731-00/?p=43...
https://github.com/mity/old-new-win32api?tab=readme-ov-file#...