return to table of content

Writing GUI apps for Windows is painful

Aurornis
100 replies
23h1m

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.

eschaton
26 replies
22h21m

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.

cageface
15 replies
14h49m

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.

throwaway2037
12 replies
12h59m

    > Documentation is poor.
This is the first I heard about SwiftUI. Maybe I am mixed up and docs are excellent for Swift, but not SwiftUI?

biztos
9 replies
11h2m

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.

throwaway2037
8 replies
10h24m

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.

biztos
4 replies
8h0m

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!

cageface
3 replies
7h32m

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:

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.

biztos
2 replies
6h0m

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.

cageface
1 replies
5h10m

Please let me know if you have any feedback or suggestions for the player.

And yes I’d feel more confident in Flutter if Google was dogfooding it a lot more.

mst
0 replies
2h29m

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.

cageface
2 replies
9h26m

I’ve had overall very positive experiences with Flutter. If I wasn’t concerned about Google’s long term commitment to it I’d use it for everything.

biztos
1 replies
7h56m

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.

cageface
0 replies
7h30m

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.

https://plastaq.com/minimoon

cageface
1 replies
12h47m

Yes. Two different things. The SwiftUI docs are mostly just listings of functions and not much explanation of how to use them.

superb_dev
0 replies
11h1m

Plus, half of the official examples are given to you as a full Xcode project that you must download and import

bobajeff
1 replies
4h16m

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.

cageface
0 replies
3h46m

Unfortunately it doesn’t seem like having good, bug free, modern and well documented desktop APIs is a priority for anyone anymore.

barrkel
8 replies
21h29m

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.

klabb3
3 replies
7h35m

There are exceptions, for very rich dense UI, for UIs that need to be cross-platform

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?

wongarsu
1 replies
4h31m

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.

MBCook
0 replies
2h49m

Right. I want your app to have consistency with the platform I’m using. Not between all platforms.

With the exception of games try to use the native GUI. It’s the best choice most of the time.

ToucanLoucan
0 replies
4h27m

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.

therein
2 replies
7h57m

and fitting in with the system theme is all you ought to aim for, most of the time

Even Microsoft struggles with that.

pc86
1 replies
4h45m

Only because they change the system theme every 45 minutes.

ToucanLoucan
0 replies
4h18m

Seriously, someone needs to reign in their UI department. No more refreshes until you actually finish one.

threatofrain
0 replies
1h21m

Or if you’re making games. All games seem to cherish a unique look even starting from the game menu or title screen.

vintagedave
0 replies
3h19m

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

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

chipdart
22 replies
22h46m

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.

Shorel
21 replies
22h30m

Isn't the issue with Qt exactly what the GPL intended?

In that case, any Qt fork would force him to also comply with the GPL, and supply the source code of his project.

deutschepost
15 replies
22h27m

LGPL. Which eliminates his requirement for a single executable. With LGPL you are only allowed to link dynamically.

jjmarr
7 replies
22h11m

The goal of this is so that end-users can modify or update Qt, the LGPL licensed component.

The LGPL is working as intended.

deutschepost
6 replies
21h38m

Yes. But the article states that they don’t care about that. They just want a single executable.

EasyMark
4 replies
19h55m

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.

ranger_danger
2 replies
17h43m

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.

riffraff
1 replies
13h5m

But a .7z requires a custom expander, .zip is natively supported by windows, isn't it?

Kwpolska
0 replies
12h21m

.7z recently got native support.

josefx
0 replies
11h23m

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.

TheCoelacanth
0 replies
4h20m

Then pay for a license or make the object files available to users who want to relink the app.

singpolyma3
6 replies
20h36m

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.

Wowfunhappy
1 replies
13h49m

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?

jcelerier
0 replies
10h22m

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

leni536
0 replies
7h44m

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.

cesarb
0 replies
1h43m

If you ship alongside your binary a bundle of eg .o files

You might even be able to use partial linking (ld -r) to ship a single .o file instead of a bunch of them.

bla3
0 replies
13h15m

The linked post does mention that:

or distribute object files for recompilation
alok-g
0 replies
5h36m

Cool!

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.

chipdart
4 replies
22h29m

CopperSpice is LGPL, not GPL.

It's not a problem.

alok-g
3 replies
5h35m

Hmm. How could that be when it's based on Qt?

Liquid_Fire
2 replies
4h10m

Qt is also available under the LGPL. There is no license advantage to using CopperSpice. I'm not sure what GP is referring to.

alok-g
1 replies
3h56m

Some parts of Qt are GPL only.

Liquid_Fire
0 replies
3h17m

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.

elpocko
15 replies
22h37m

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

userbinator
4 replies
22h3m

It's also suited to games, where "non standard" UI is expected and part of the experience.

delta_p_delta_x
3 replies
13h32m

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

spookie
1 replies
9h35m

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

summerlight
0 replies
7h26m

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.

bun_terminator
3 replies
22h27m

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.

fuzztester
2 replies
3h30m

Due to what reasons does imgui offer incredible development speed?

bun_terminator
1 replies
2h19m

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.

fuzztester
0 replies
1h33m

Thanks, got it.

throwaway2037
2 replies
12h58m

    > proper keyboard support
Specifically, what does this mean?

TJSomething
1 replies
11h47m

I currently see two international keyboard issues:

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

throwaway2037
0 replies
10h26m

Excellent reply. I did not consider international keyboards when I writing my reply. And gaming companies are definitely targeting international markets in 2024!

ranger_danger
2 replies
17h44m

ImHex uses it for the entire UI

oblio
0 replies
9h49m

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

rty32
8 replies
14h7m

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.

beagle3
3 replies
10h59m

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.

rfoo
1 replies
9h59m

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?

beagle3
0 replies
6h53m

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.

ClumsyPilot
0 replies
5h17m

In 1999, I built a completely custom Win32 GUI for a (brandable) chat application

Given that it’s windows, it might still run today, so it likely is still possible

alok-g
2 replies
5h42m

Winamp comes to mind as a counter example.

hermitdev
1 replies
2h8m

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.

alok-g
0 replies
1h38m

+1.

I still use Winamp, and essentially in its 2.x mode.

abareplace
0 replies
5h36m

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.

EasyMark
8 replies
19h57m

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)

smackeyacky
7 replies
19h41m

Which particular .NET Gui? There is a collection of them: MAUI, WPF, Blazor Hybrid, WinUI.

Microsoft have utterly screwed the pooch on getting their .NET GUI story straight.

ivm
3 replies
15h1m

WinUI 3 is the default for Windows-only applications

pjmlp
1 replies
8h24m

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.

CrimsonCape
0 replies
19m

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?

LordDragonfang
0 replies
13h55m

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.

wvenable
0 replies
13h38m

In my opinion, WPF is the logical choice. Still.

jen20
0 replies
18h46m

Probably Windows.Forms unless there’s a REALLY good reason to do anything else.

alkonaut
0 replies
8h50m

Don't forget Avalonia. Looks like it's going to be the sensible WPF version.

dokka
4 replies
22h14m

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.

fuzztester
3 replies
14h10m

I still use Windows Forms in .NET 4.8 and my executables are < 1mb

Do you need to ship any supporting files separately, along with the app?

And is .NET 4.8 or higher already on Windows PCs?

throwaway2037
0 replies
12h54m

.NET 4.8 is default in Win10/11 now.

WorldMaker
0 replies
2h34m

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

EnigmaFlare
0 replies
8h49m

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.

slaymaker1907
1 replies
1h46m

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.

dgellow
0 replies
1h43m

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

pc86
1 replies
4h46m

he didn't want to pay for a license

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

throw__away7391
0 replies
1h54m

stay away from Electron

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.

jocoda
1 replies
13h12m

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.

cratermoon
0 replies
12h7m

"Writing small, custom styled GUI apps for windows is painful"

I'd add "for free because I'm too cheap to buy a license for a toolkit that does what I want".

PaulHoule
1 replies
3h23m

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.

mst
0 replies
2h24m

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.

ClumsyPilot
1 replies
5h23m

Agreed, this is a bit like writing ‘developing iPhone app is painful’ but not using anny officially supported tooling.

fact that you must ship the app Unpackaged is particularly strange.

wkat4242
0 replies
17h16m

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.

userbinator
31 replies
22h22m

Problem: It is extremely hard to stylize native Win32 controls.

That's not a problem, it's a feature. I am absolutely bloody sick of apps that go out of their way to reinvent the standard UI controls in perplexing ways and behave unexpectedly. Following the system UI preferences is what you should do, and it irritates your users if you don't.

There is a “hidden” dark mode for Win32 controls used by Windows File Explorer that you can activate, but it covers only some of the controls and still doesn’t look good.

Don't do that. If you use the regular Win32 controls then they will automatically get the styling the user has set.

I've been writing Win32 apps for close to 30 years now. It's sad to see the regression in UIs over the years.

ricopags
7 replies
22h9m

Never coded a GUI app but speaking of regressions:

As a heavy windows KB user, losing the ability to alt+letter all the things to /quickly/ navigate windows apps is incredibly frustrating.

I've read that Mac OS envy infiltrated the WinUI time and while some may prefer the aesthetics, on Windows 11 apps like mspaint I can no longer navigate anywhere near as quickly.

From milliseconds to multiple seconds.

I'm incensed at this change personally, and I feel totally confused by it from the perspective of MS. In the era of AI and automation, slower screen draw times will make a significant impact to performance and energy use. I hope someone like Mark Russinovich, Kevin Scott, or Satya Nadella will notice and change course.

hobs
4 replies
22h6m

It's funny that you mentioned apple because their system shortcuts are integrated as hell and they even let you map them in the OS -> App level, way better than anything MS has ever shipped.

jwells89
3 replies
21h53m

Yep, among other things both Apple-unique and emacs-esque text navigation shortcuts are in every native textfield across all apps and anything that's a menu item in any app can have its shortcut key rebound in System Settings without any extra work on the part of third-party devs.

It's one of the reasons why longtime Mac users are disinclined towards non-native apps. Most don't bother to reproduce these behaviors, and so when you as a user go to reach for these features that you have muscle memory for and they're not there, it's like hitting a brick wall in the middle of your workflow and makes the app in question feel basic and unrefined.

Hamuko
1 replies
21h40m

Annoyingly enough you don't really all keyboard shortcuts out of the box even if you build natively. If you create a Button(role: .destructive).keyboardShortcut(.defaultAction) in a SwiftUI dialog, you don't get Cmd+D as the shortcut even though Finder (and I think other apps too) uses Cmd+D as the keyboard shortcut for destructive confirmation dialogs. Thankfully at least a Button without destructive role will get Enter as its keyboard shortcut in the same context.

jwells89
0 replies
21h35m

Yeah for now I keep most of my usage of SwiftUI restricted to non-Mac platforms. On macOS it’s fine for smaller bits like collectionview cells but has a number of rough edges for more major use cases.

hobs
0 replies
20h52m

Don't forget you can type any of those menu items in the help dialog and it will not only tell you where it is, and not only let you activate it, it will helpfully show you the deeply nested set of submenus required to activate it.

Oh and of course those shortcuts are activateable by other applications to simplify app integration.

vel0city
0 replies
3h25m

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

Dwedit
0 replies
21h47m

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

crazygringo
7 replies
22h16m

As a non-Windows user, I'm confused, maybe you can clarify:

If you use the regular Win32 controls then they will automatically get the styling the user has set.

Does that mean they'll get dark mode if the system is in dark mode?

In which case I don't understand what the author is complaining about. Sounds like dark mode would be working as intended.

They want "easy styling" but I took that to mean things like icons, some colors, etc. Not totally replacing what buttons look like. I agree -- being consistent with the OS is a good thing.

Rohansi
2 replies
21h50m

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

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

mrpippy
0 replies
21h41m

Correct. For Win32 apps, the only official support for dark mode is some WinRT APIs to tell if it’s enabled, so you can “adjust your application's painting and rendering code to use a Dark mode color set”

https://learn.microsoft.com/en-us/windows/apps/desktop/moder...

ack_complete
0 replies
18h26m

Also changing those old themes has a good chance to "break" any (poorly made) apps doing their own themes.

They already do this. COLOR_3DFACE has gotten brighter with each successive version of Windows and in Windows 11 is #F0F0F0. I've had to fix UIs that became unreadable as a result.

jenscow
1 replies
21h39m

Those colour settings are not aware of Windows 11's "Dark mode"

userbinator
0 replies
21h3m

Not surprising. Typical "modern" Microsoft. Reinventing things poorly is so common these days.

abareplace
0 replies
4h52m

No, they won't get dark mode and this is the biggest problem for Win32 UIs now. If Microsoft would make dark mode available for classic Win32 apps, it would meet all requirements of the original poster.

EvanAnderson
6 replies
22h14m

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

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

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

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

jenadine
3 replies
21h12m

You seem to be in the minority with that thought.

The evidence is that most apps nowadays comes with their own style, often packed in a HTML frontend.

Users are used of websites which all have their own designs, and don't seem to mind if all apps have different look and feel.

userbinator
0 replies
21h6m

Most users have just developed a learned helplessness. It doesn't mean they don't like it.

surfingdino
0 replies
20h29m

Devs that learned web frontend dev are not familiar with OS GUI guidelines. When I tell them Apple used to publish GUI guidelines for Mac application developers they stare at me in disbelief.

analog31
0 replies
14h6m

Most users are unaware that there are UI standards, and have no basis for comparison. They use Google to help them figure out how to use apps, and take hand-written notes on how to find the things that they need. Once they figure out the functions in an UI that they need, they just pray that it doesn't change. The average user experience is horrific.

zigzag312
1 replies
6h55m

I want software I'm running to look like the rest of the OS

This is an impossible task on Windows, as it has multiple, inconsistent UIs by itself.

EvanAnderson
0 replies
6h31m

I want the apps I run on Windows to look like other Win32 apps. I want them to use native Windows controls.

All the UI "enhancements" in Windows 8 and subsequent versions are garbage and irritate me just as much as any other non-Win32 native UI.

serial_dev
2 replies
22h9m

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

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

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

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

MaxBarraclough
1 replies
22h2m

They also often want to use web technologies and/or cross-platform GUI toolkits, to avoid reimplementing their UIs.

eschaton
0 replies
21h13m

And all because they fundamentally believe that their development time and expense is worth way more than their customer’s time and expense.

withinrafael
0 replies
21h47m

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

troupo
0 replies
21h45m

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

leapingdog
0 replies
20h18m

I agree with you.

Easy styling, including dark mode

I wonder if this requirement has been imposed from above.

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

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

TheChaplain
0 replies
21h47m

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

Sakos
0 replies
22h8m

It's even worse.

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

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

alkonaut
22 replies
22h46m

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.

chipdart
13 replies
22h43m

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.

smileybarry
10 replies
20h3m

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.

neonsunset
5 replies
19h10m

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.

smileybarry
2 replies
18h22m

It’s just because the WinUI3 libraries and/or .NET Core runtime take that much. Mostly WinUI3 IIRC.

And that’s when you use “selfcontained mode” rather than AOT publishing, now with AOT it’s considerably better.

neonsunset
1 replies
18h15m

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.

pjmlp
0 replies
8h18m

If only UWP had a AOT compilation story for .NET code that could be re-used for WinUI 3.0....

And then there is the whole C# / C++ interop between CsWinRT and C++/WinRT.

pjmlp
0 replies
8h19m

You should browse the set of WinUI related repos, YouTube community calls and Developer Connection, feedback is something they aren't short of.

pjc50
0 replies
9h47m

WinUI3 itself.

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

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

whywhywhywhy
3 replies
5h20m

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.

HumblyTossed
1 replies
5h2m

Like shouldn't Windows 11 just either have that already or pull it down as needed as it's an official MS library.

In this day and age of everything always connected, some things still aren't always connected.

estebank
0 replies
2h25m

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.

WorldMaker
0 replies
2h22m

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.

pjmlp
0 replies
20h41m

Anyone that has used WinUI since its inception, knows that the best for our sanity is to avoid it at all costs.

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.

mike_hearn
0 replies
21h28m

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.

vunderba
7 replies
22h25m

Agreed. I had the exact same question.

From the article: "The issue is that with bundling the .dll, it would still mean it being extracted somewhere and writing additional code for the P/Invoke to work, and C++/CLI gets compiled to .NET IL code, in other words, you can open the resulting app in dnSpy and see the C++ code translated to C# equivalent (which is not what I want, I want native code)."

I don't understand what the author is talking about. When they say the C++ code will be translated to the equivalent c#, that's not how interop works at all... the native C++ DLL is not somehow made magically more vulnerable to reverse engineering because you can p/invoke to it.

smileybarry
3 replies
20h1m

C++/CLI is managed code, it’s basically C++ compiled into .NET IL.

If you’re writing C++ code running on .NET / .NET Framework, you’re basically writing masochistic C#.

alkonaut
1 replies
19h10m

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.

smileybarry
0 replies
18h21m

But why even use C++ for the front end if it’s going to be .NET?

Because the author of the article wanted to use C++, I don’t know why. That’s why I called it “masochistic C#”.

pjmlp
0 replies
8h15m

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.

delta_p_delta_x
1 replies
22h18m

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.

alkonaut
0 replies
19h9m

That insistence isn’t motivated in the post in any way, which makes it a really weird and arbitrary requirement.

TheDudeMan
0 replies
12h29m

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.

popcalc
19 replies
23h15m

As a fellow European, I do not have air conditioning.

Is anything stopping the author from buying a heat pump?

bpfrh
14 replies
23h7m

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

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

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

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

edit: qualified the law statement

mdorazio
12 replies
23h2m

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.

bpfrh
4 replies
22h56m

They are but not as efficient and so most people don't bother(that I know of).

Paradigma11
2 replies
20h3m

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.

throwaway2037
1 replies
13h1m

2400 EUR? Cripes, that is expensive. Do you mind to share the model?

Paradigma11
0 replies
1h38m

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.

Ciantic
0 replies
22h16m

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.

gibsonpil
3 replies
22h57m

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.

ranger_danger
1 replies
14h50m

Can you name one place where this is an enforceable rule?

throwaway2037
0 replies
13h2m

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

bpfrh
0 replies
22h51m

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.

whstl
0 replies
21h14m

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.

coolgoose
0 replies
22h37m

They are available

asmor
0 replies
22h56m

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.

ranger_danger
0 replies
14h50m

Swamp coolers are cheap and don't need a window or drain.

userbinator
0 replies
21h55m

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

tjoff
0 replies
23h8m

Usually, living in an apartment.

gibsonpil
0 replies
22h59m

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.

cladopa
0 replies
22h16m

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.

Lariscus
18 replies
19h47m

I have a very low opinion of developers who decry having to pay for a commercial licence for otherwise LGPL licensed software libraries. They expect to be paid for their work, and ensure that by creating closed source software. That's fair enough. Yet, the devs that solved the actually difficult parts of creating a UI library have to be utter saints who freely bestow a gift of code upon the world.

hsn915
12 replies
8h0m

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

Lariscus
8 replies
7h13m

I have little sympathy for that kind of argument, imagine a carpenter complaining that they have to buy wood and nails. Besides, a Qt license for small businesses is nowhere near thousands of dollars. Only in software development do we expect quality tools to be given to us free of charge with no strings attached.

daemin
5 replies
7h6m

Qt for Application Development Professional (ADP) is 3460 €/Year.

If you're making something which you sell for $50 or so you'd need 100 sales per year to just pay for the development environment. That also assumes that it took you less than a year to make said product.

Lariscus
4 replies
5h35m

'Qt for Application Development Enterprise - Small Business (ADE-SB)' is $499.

daemin
3 replies
5h27m

You're right. I didn't see the Small Business tab when I was quickly looking through it.

Still ends up being a blocker when you're not sure how many copies of the product you'll sell.

Lariscus
2 replies
4h55m

I guess that is just one of the many risks you have to take if your trying to build a business. A couple of hundred dollars in licensing fees are not going to sink your product. For a side project that you don't expect to make any money it might be too much, but in that case you could just as well open source the project.

pantulis
0 replies
2h14m

but in that case you could just as well open source the project.

Which doesn't necessarily mean you cannot get paid for it.

CSSer
0 replies
2h3m

It's also worth considering that the value of this license is very likely not a net loss even if your initial product doesn't work out.

hsn915
0 replies
2h33m

Your take is very weird.

He's shopping around. When something is out of his budget it's natural to not buy.

dvngnt_
0 replies
1h44m

wood makes sense to pay for. wood doesn't grow on trees. software works a bit differently though it should also be paid for

daemin
2 replies
7h11m

It's especially hard when the application you're building isn't yet proven. As there's no guarantee that it will get any sales, let alone enough to cover the Commercial Qt expenses.

jnhzubh
1 replies
2h32m

You do not have to pay before your first sale.

And $500 is laughable small compared to developer salary. If it saves you half a day of work, you are covered

hermitdev
0 replies
10m

There is a huge gulf between saving a half a day of work versus _having_ $500 to spend on a tool that would save you that half day of work.

kelnos
2 replies
12h34m

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

eptcyka
1 replies
5h58m

Whilst I don't understand the users who are hell bent on having a single-executable work, if you have users who are hell bent on using but a single executable, you have to meet them where they're at.

jnhzubh
0 replies
2h14m

In my experience Windows users don't care about the statically linked part

What they care about is having an executable and not needing a zip with dlls

And that is trivially achievable by bundling the dlls into the exe file

zer0zzz
0 replies
1h17m

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

madduci
0 replies
11h41m

Exactly this.

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

mjevans
15 replies
22h58m

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.

criddell
4 replies
22h42m

need to agree on a GUI interoperability

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

linguae
3 replies
22h22m

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.

torstenvl
0 replies
21h28m

wxWidgets does this pretty well, e.g., wxSingleChoiceDialog has "OK" "Cancel" on Windows but "Cancel" "OK" on Linux/GTK.

swatcoder
0 replies
22h13m

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.

criddell
0 replies
21h36m

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.

torstenvl
2 replies
22h32m

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

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

mjevans
1 replies
13h5m

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.

torstenvl
0 replies
5h58m

Your previous post said

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.

nasretdinov
2 replies
22h55m

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.

linguae
1 replies
22h28m

There was an implementation of OpenStep for Windows named OpenStep Enterprise:

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.

WillAdams
0 replies
18h6m

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.

cxr
1 replies
21h40m

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.

mjevans
0 replies
13h6m

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.

userbinator
0 replies
21h54m

That's called WINE. ;-)

Win32 Hello World messagebox is a few hundred bytes.

Androth
0 replies
16h2m

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.

markus_zhang
13 replies
22h39m

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.

bonzini
4 replies
22h27m

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

Jare
2 replies
21h58m

That's what it was, mostly.

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.

markus_zhang
0 replies
19h25m

I don't know much about the performance, but I guess non-action games should be fine?

bonzini
0 replies
21h45m

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.

markus_zhang
0 replies
22h18m

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.

qingcharles
2 replies
21h50m

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

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

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

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

markus_zhang
1 replies
19h21m

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.

pjmlp
0 replies
8h1m

Yes, he and Id pushing miniGL are pretty much why Glide lost and everyone was into MS-DOS and OpenGL graphics for a while.

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

userbinator
1 replies
22h14m

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?

markus_zhang
0 replies
19h26m

Thanks, I don't know about that yet, so it's going to be while.

For the string it's mostly the wchar and char stuffs. I think I'm getting a hang of it.

pjmlp
0 replies
8h5m

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

pjc50
0 replies
9h39m

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

ogoffart
12 replies
22h48m

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.

CyberDildonics
5 replies
20h55m

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?

utensil4778
2 replies
20h40m

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

wordofx
0 replies
11h13m

You already have that as a .net dev.

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.

neonsunset
0 replies
18h58m

This has been solved since .NET 6/7 and the results should pleasantly surprise you:

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

    dotnet publish -o out -p:PublishSingleFile=true -p:PublishTrimmed=true
Also, I just tried worker template (it includes generic host, DI, logger, etc.) and it's only 5 MiB when AOT compiled on macOS:

    dotnet new worker --aot
    dotnet publish -o out
Will likely take less on Windows and Linux.

leapingdog
0 replies
20h0m

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.

davidhyde
0 replies
18h57m

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.

IshKebab
1 replies
22h25m

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

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

ogoffart
0 replies
22h18m

40MB was the criteria coming from the article. But it's much smaller than that. I don't have the exact number in mind. I'd say much less than 20MB.

user_7832
0 replies
9h31m

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!

hoten
0 replies
11h16m

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.

fuzztester
0 replies
13h50m

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.

StarterPro
0 replies
22h9m

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

markasoftware
12 replies
23h6m

More accurately:

+ "portable" (single exe with no automatic unzipping of dlls or anything)

+ commercial and unwilling to redistribute compiled object files (which together with the "portable" requirement, means no LGPL)

+ dark mode

Windows GUI apps is painful. Drop any one of these requirements and there are good established options.

Specifically I think most "portable" applications use win32 because, usually, portable => small, simple application where functionality is more important than dark mode or other styling ability.

CyberDildonics
6 replies
23h5m

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

criddell
2 replies
22h45m

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.

CyberDildonics
1 replies
21h20m

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.

throwaway2037
0 replies
12h47m

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.

moal
0 replies
2h7m

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.

fuzztester
0 replies
9h13m

Or with Lazarus, I've tested it a year or so back. Under 50KB, IIRC, for a CLI Hello world app, though, not a GUI one. Similar size with a D app.

chipdart
3 replies
22h38m

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?

temac
0 replies
20h38m

"Portable" i could see a few use cases. No MSIL and only native code, however...

pjmlp
0 replies
20h38m

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.

dfox
0 replies
21h46m

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.

ranger_danger
0 replies
17h37m

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

throwaway2037
11 replies
13h8m

Reading many of these comments makes me realise that the whole premise is flawed. I "vote" to rename this blog post as:

    > Writing GUI apps for Windows is painful when requirements are unrealistic
They should try to target .NET Framework 3.5 using WinForms. That is my best suggestion, as all recent versions of Windows will have this installed (at least).

taspeotis
6 replies
13h2m

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

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

AmateurAlert
5 replies
10h54m

AOT is currently only available in CLI apps. It's expected for WinUI 3 apps using WASDK v1.6 closer to the end of the year.

neonsunset
2 replies
8h5m

Not limited to CLI (even at release in .NET 7 it was possible to use it with ASP.NET Core with limitations and there were custom templates to make it work with some GUI framework I think, and MonoGame already worked partially), certainly not in .NET 8. I’m not sure about WinUI 3 itself, but a lot of things today are AOT compatible.

And naturally single-file + trimmed works almost everywhere, in some situations requiring to add attribute annotations for un-analyzable reflection usage patterns.

pjc50
1 replies
4h11m

"Single file" has the annoying property that it unpacks all your assemblies at runtime and dumps them in a temporary directory. There's no good reason it couldn't byte-load them directly out of the executable instead.

neonsunset
0 replies
3h48m

Do you mean IncludeNativeLibrariesForSelfExtract attribute? This is a related but still separate feature. If you mean the managed assembles, then it works differently:

"Only managed DLLs are bundled with the app into a single executable. When the app starts, the managed DLLs are extracted and loaded in memory, avoiding the extraction to a folder. With this approach, the managed binaries are embedded in the single file bundle, but the native binaries of the core runtime itself are separate files."

https://learn.microsoft.com/en-us/dotnet/core/deploying/sing...

For """embedding""" native dependencies into the binary without self-extract, you can't really do that, the closest alternative is statically linking them into AOT compilation instead (but that gets tricky with large dependencies).

taspeotis
0 replies
8h36m

Oops, I googled it and you’re right.

alkonaut
1 replies
8h46m

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

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

brnt
0 replies
23m

Why 4.6 and not 4.8? (I assume you mean .Net Framework and not .Net.)

bux93
0 replies
3h47m

The requirements are not just unrealistic, but, you know, wrong?

It is extremely hard to stylize native Win32 controls.

Yes, it should be! I know Microsoft is errant in its ways itself, but controls should not be custom, they should be standard.

ack_complete
0 replies
9h10m

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

cjk2
11 replies
23h3m

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.

7thaccount
8 replies
22h59m

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.

cjk2
7 replies
22h53m

Totally agree with this.

I’ll get shot for this one but I write most of my GUIs in Excel these days.

mordechai9000
6 replies
22h40m

Do you mean Visual Basic for Applications? How are you creating a GUI in Excel?

hnthrowaway0328
4 replies
22h31m

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.

mordechai9000
2 replies
22h16m

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.

cjk2
1 replies
21h15m

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.

Gibbon1
0 replies
21h11m

Reminds me of Moe on the Simpsons saying I've done things I'm not proud of. And the things I am proud of are disgusting.

You should be proud like that.

jmkni
0 replies
6h50m

I remember using Office Interop back in the day

Less useful these days as we use open formats, ie doc is propriatery, docx is open

cjk2
0 replies
22h0m

Mostly just locking fields. I don’t do anything procedural. It’s usually calculators, stats and modelling stuff.

chipdart
1 replies
22h26m

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.

cjk2
0 replies
21h16m

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.

Const-me
11 replies
21h57m

For requirements like that, I typically write WPF C# frontend, combined with C++ backend. Compared to ImGui, in WPF you’ll get a GUI designer, styling which allows easy dark mode, data bindings, data templates, animations, IDE support like live visual tree inspector, accessibility support, and more.

If you use the legacy .NET 4 framework, the .NET runtime will come pre-installed on modern Windows. If you compile your C++ DLL with static C runtime, your C++ DLL won’t have any dependencies apart from OS components like kernel32.dll.

If you insist on having a single EXE you’ll need to bundle it and extract, but the additional code for the P/Invoke to work is like 4 lines of that code, call LoadLibraryW from kernel32.dll early on startup, before using any stuff with [DllImport] from that DLL.

I do not recommend C++ CLI. Write normal C++ which compiles into native code without any weird metadata. You can use C APIs, or COM interop with ATL, or check this library of mine https://github.com/Const-me/ComLightInterop/

If you start with this approach (as opposed to refactoring a C++ app you already have) you’ll find out that you need substantially less C++ than you expected. Essentially, C++ is only required for 2 things: CPU-bound number crunching, and code which consumes large C or C++ libraries (Windows SDK is huge and pieces like D3D or MediaFoundation require C++). It’s much easier to do everything else in C#, as the language and especially the standard library are just better.

glzone1
9 replies
21h32m

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

pjmlp
4 replies
20h30m

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

glzone1
3 replies
13h47m

Haha.. That is too funny - I haven't been following this closely anymore. It's honestly wild. Does WPF still do data binding by reflection? I can usually "feel" a WPF app if I'm doing a lot of data work.

I remember when WinForms (which I thought was fine!) was killed. Why they just didn't continue to build on that I don't know (yes, I've heard the explanations, the importance of things like having XML (barf) in the framework).

How can you not be absolutely kicking butt on your own platform with a great story especially because they absolutely HAD a great story both at entry level LOB and advanced LOB.

pjmlp
1 replies
11h34m

Supposedly is being worked on for making it more Native AOT friendly.

How we got into this mess? WinDev and DevDiv politcs.

After the Longhorn debacle, its technologies landed on DevDiv, like WCF and WPF.

Sinofsky and friends never were that keen in having .NET coming into their turf, it is no surprise that Hilo sample for Windows 7, then praises COM and C++ for Windows applications[0][1].

Then coming in this path, WinRT came to be, with roots as how .NET was being designed, before Microsoft decided to pivot it as another Java like technology[2].

A bunch of folks in WinDev, weren't happy with C++/CX, so they united to replace it with C++/WinRT, because extensions, when clang and GCC are full of extensions, promised to give back a C++/CX like developer experience in 2017[3], never delivered, went to have fun with Rust/WinRT.

Now C++/WinRT is in maintenance mode[4], and Rust/WinRT never took off, and is now Rust/windows-rs[5].

As paying customer, impacted by those childish attitudes, I would have had the whole team fired.

Finally, check the amount of bugs and complaints on their respective repos,

https://github.com/microsoft/microsoft-ui-xaml https://github.com/microsoft/WindowsAppSDK https://github.com/microsoft/cppwinrt/

And then compare with Project Reunion vision from 2021, and where we are three years later

https://blogs.windows.com/windowsdeveloper/2021/03/29/announ...

Mainly because along the way, as if those changes weren't enough, they also decided to reboot their initial approach with Project Reunion, WinAppSDK took another route, and here we are.

This is only a short overview of how WinRT went down since Windows 8, thus only those that never advocated for it, can honestly suggest WinUI, as they lack the background of how chaotic it all is.

[0] - https://devblogs.microsoft.com/cppblog/announcing-hilo/ [1] - https://learn.microsoft.com/en-us/previous-versions/msdn10/f... [2] - https://arstechnica.com/features/2012/10/windows-8-and-winrt... [3] - https://www.youtube.com/watch?v=7TdpWB_vRZM&t=2983s [4] - https://github.com/microsoft/cppwinrt/issues/1289#issuecomme... [5] - https://github.com/microsoft/windows-rs

glzone1
0 replies
34m

This at least explains what from the outside looks like total insanity.

What's been confusing is they've been chasing all sorts of things (phones / tablets / web development) so clearly had money to burn, but couldn't deliver a basic solution for their own platform.

Clean simple line of business apps (ie, datagrid / listviews needs to work etc with bigger excel type datasets) + maybe RemoteApps or some other remoting option for SAAS type deployment would have been a nice option to have for plenty of folks.

For a lot of use cases the modern solutions are both worse to develop for AND are slower / buggier - so you get little for the effort

Kwpolska
0 replies
12h4m

WinForms is still actively developed (although it wasn't always).

I prefer XML to manually placing controls in a window and clicking around a designer GUI at all times. XML is trivially editable by hand, WinForms auto-generated C# isn't.

Const-me
2 replies
21h10m

UWP was designed primarily for Windows phones, usability on desktops suffers. And it requires windows store, you can’t just ship an installer .exe

WinUI seems to be copy-pasted from UWP, same usability issues on desktops. Unlike UWP, it’s a mess in terms of software quality. Also the runtime is huge, I think the size in MB even exceeds Electron.

About MAUI, it seems Microsoft decided to make an abstraction over native controls. It’s been tried for decades and it always results in the same suboptimal result because these GUI frameworks implement the least common denominator of available UX. In addition to that, on Windows that thing uses WinUI3 backend, see the previous paragraph.

I don’t know anything about Blazor, but it seems that thing is for web apps?

pjmlp
1 replies
8h10m

MAUI is basically Xamarin.Forms, rebranded and rewritten, thus forcing the whole Xamarin community to rewrite their stuff, or go elsewhere.

Miguel de Icaza is pretty sour on this, and quite likely one of the reasons he is now fully into Apple ecosystem and Swift.

Blazor started with being only a WebAssembly based framework, then they decided to put everthing on ASP.NET under Blazor umbrella, and are now pushing Blazor into everything that has a Webview, including the stupid idea of Hybrid Blazor in MAUI, basically Electron in .NET.

glzone1
0 replies
27m

Blazor is interesting. They are biting off an absolutely metric done of stuff. I will say their development style -> social media etc seems good which might help drive some buyin. They have public roadmaps. The outcomes still pretty rough ("Could not reconnect to the server") when falling off the happy path. So it still had a bit of that "in theory" development style that in terms of use annoys developers.

gardaani
0 replies
9h46m

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

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

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

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

I don't know about MAUI / Blazor.

kumarvvr
0 replies
4h55m

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

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

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

beart
10 replies
22h57m

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.

glzone1
4 replies
21h37m

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.

kmeisthax
1 replies
13h2m

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 engineering support and developer experience.

USER is an enhanced clone of the MacOS API, so it's natural to see what Apple did when confronted with the same problems. MacOS didn't have an object system at all, you just threw a bunch of controls onto a list and the system rendered them. That (along with user mode applications) was actually one of the reasons why they bought NeXT. OSX's AppKit toolkit shipped with compatibility bridges for Toolbox apps, but it was still about as advanced as USER was when it came to GPU usage, given that it was built around the same era as Windows, just for beefier hardware.

So what did Apple do? They made AppKit speak layers. They wrote a whole new compositing system called CoreAnimation to do in-process compositing, with all the common controls knowing how to manage it and layer-unaware third-party controls just doing whatever made sense. And this itself was a trojan horse for UIKit: the compositing library had been written to support a touch tablet demo that was later rolled into the Purple project to produce the iPhone. Y'know, the thing that actually kicked Microsoft's ass so much they decided to fracture their development ecosystem into 40 different UI toolkits with confusing names. In comparison, on modern macOS the big split comes from SwiftUI and Catalyst, but those are both wrappers around AppKit controls rather than ground-up rewrites of UI toolkits nobody dares touch.

[0] Or possibly Pascal, given the MacOS heritage

[1] The correct way to do high-DPI is for the windowing toolkit to work exclusively in virtual coordinates. Physical device coordinates and their derivatives should be converted away from at the earliest possible convenience and converted back into as late as possible. At a minimum, no user-facing APIs should use physical coordinates.

USER does not do this, even though there's an option to make it do this, which has worked wonders on every non-DPI-aware app I've thrown at it.

[2] Or, alternatively, implement their own. My favorite story about this is Internet Explorer, which ships with it's own implementations of common controls specifically just so that HTML form elements don't have to hold an HWND each and can share the parent window.

glzone1
0 replies
10m

The mess this made showed up everywhere.

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

akira2501
1 replies
20h55m

The emphasis on Universal Windows Platform as "the future" of app development is absurd.

Remember when Microsoft honestly thought they had a shot at making a mobile platform to compete with Android and Apple?

shortrounddev2
0 replies
4h2m

Say what you will about their chances of succeeding, but the Windows phone is the best phone I ever owned

Dwedit
1 replies
21h45m

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.

shortrounddev2
0 replies
3h52m

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#

jb1991
0 replies
22h19m

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.

cageface
0 replies
14h42m

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.

bowsamic
0 replies
22h17m

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

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

api
10 replies
23h16m

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.

Aurornis
6 replies
23h9m

Today UI apps use 100X more memory,

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

I also have literally 100X more RAM now.

are slower,

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

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

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

Closi
3 replies
23h3m

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.

Closi
1 replies
12h52m

It was!! That’s absolutely amazing, what a surprise after all these years :)

Many thanks for hunting me down in some comments!

kirubakaran
0 replies
3h36m

Awesome, I'm so happy to hear that!

wiseowise
0 replies
20h58m

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.

beart
0 replies
23h3m

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.

MrMember
2 replies
23h5m

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

lylejantzi3rd
1 replies
7h42m

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.

api
0 replies
4h56m

Later versions of Visual Studio with custom controls and other abstractions made fairly complex GUIs entirely doable and still pretty fast to build.

Then they shit canned everything for Xaml around the same time the whole industry abandoned any kind of WYSIWYG or rapid development technology.

withinrafael
5 replies
21h32m

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

mike_hearn
2 replies
21h28m

You can opt out of those with manifest metadata. Capabilities aren't enforced if you distribute out of the app store.

withinrafael
1 replies
20h28m

The OS will enforce them at installation/launch time regardless of distribution method.

mike_hearn
0 replies
9h29m

Yes but what I mean is you can declare any capabilities you want, nothing prevents you just asking for whatever you need except Store review.

withinrafael
0 replies
20h28m

Note the warning on the page.

This element requires the unvirtualizedResources restricted capability.

And if you click through the restricted capability link:

If your app declares any restricted capabilities, then you must provide info during the app submission process in order to be approved to publish your app to the Microsoft Store.
zerr
0 replies
20h45m

Where's the GUI designer?

pjmlp
0 replies
20h37m

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

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

jenscow
0 replies
21h29m

For >1 minute incremental compile times? No thanks.

mathverse
6 replies
22h25m

Sciter desperately needs an evangelist who can reply and help people with their problems and just in general provide support and work on the ecosystem. I think from what I remember from indiehackers you are not there yet to be able to afford it but we desperately need that.

Even paying pravic to keep the libraries for different languages up to date would be of great help.

c-smile
5 replies
22h12m

Sciter's support forum is pretty active : https://sciter.com/forums/

Mr. Yuri (Pravic) has his own agenda these days. As far as I know creation of Go, Rust and Python backends for Sciter was a method for him to determine best frontend technology for his organization.

If someone wants to take care about Go, Rust and Python wrappers - let me know.

mathverse
4 replies
21h47m

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

c-smile
2 replies
21h40m

1. These wrappers are Open Source.

2. I do not have customers that requested either one of these wrappers.

3. Customers that do use one of wrappers, as AdGuard for example, maintain their own version of Sciter/Go: https://github.com/AdguardTeam/go-sciter

mathverse
1 replies
11h10m

What kind of license do I need to buy for the bindings to be updated?

c-smile
0 replies
1h30m

As with any other Open Source project - contact its author and discuss with him/her.

pests
0 replies
18h46m

Might end up being yourself.

Q6T46nT668w6i3m
7 replies
23h4m

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.

somenameforme
4 replies
22h29m

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.

cjbgkagh
1 replies
22h13m

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.

temac
0 replies
20h43m

Also, iirc there is no Windows department anymore at MS. Hard to make a great platform in these conditions.

WorldMaker
1 replies
2h10m

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.

somenameforme
0 replies
1h27m

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.

[1] - https://github.com/microsoft/microsoft-ui-xaml/issues/5917

jwells89
1 replies
21h59m

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.

eschaton
0 replies
21h15m

UIKit is actually nearly 20 years old and AppKit is getting close to 40…

magicalhippo
6 replies
22h57m

Writing GUI apps for Windows in C++ is painful

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.

chipdart
3 replies
22h36m

Writing GUI apps for Windows in C++ is painful

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

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

rubymamis
0 replies
12h16m

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.

magicalhippo
0 replies
22h23m

I've used Qt a lot. Unless something very drastic has happened last 5-6 years it's not in the same league as say Delphi.

But fair enough, it's quite good. If I had to write a C++ UI application, it'd be on my shortlist.

dgfitz
0 replies
22h23m

Writing a gui in Qt is so simple anytime someone like the GP says “writing a gui in c++ is hard” obviously hasn’t tried.

nurettin
0 replies
22h41m

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.

Androth
0 replies
16h11m

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.

banish-m4
6 replies
20h52m

A. If a gun were placed to your head and you had to write a native Windows app, what stack would you use?

B. And, if you had to write a cross platform app, which framework would you use?

bruce343434
1 replies
20h32m

A. imgui and SDL2

B. imgui and SDL2

banish-m4
0 replies
13h16m

That's not what I asked...

tored
0 replies
7h58m

A. PureBasic

B. PureBasic

qw
0 replies
5h54m

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

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

B: Kotlin compose or Delphi (

petabyt
0 replies
39m

libui libui

bloblaw
0 replies
3h20m

I presume we are talking about GUI programs:

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

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

asveikau
6 replies
21h35m

It would require me to write a custom paint function for every single control, which would take so much time I could raise a family in the meantime

This is a weird comment that shows the philosophy of old school win32 has not clicked for them. The key element in win32 is the wndproc. Most controls ask their parent what color they should be via a window message.

If you find this inconvenient, wrapping that in a small library to remove boiler plate is not a big deal.

ack_complete
5 replies
21h15m

Most controls ask their parent what color they should be via a window message.

There are a LARGE number of areas where this is not provided, such as the text color of a disabled control or the checkbox area of a checkbox control. Even for the cases where such customization points were provided, many of them were broken when theming was added in Windows XP and in comctl32.dll version 6 in Vista, which ignores some of them in favor of theme colors or images. Menu colors, for example, are ignored when theming is enabled.

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

MikeTV
4 replies
20h39m

Do you happen to have links to any good documentation/articles on this topic? I'm working on what amounts to a dark theme for Win32 controls and largely making it up as I go along, relying on tidbits and off-hand mentions from defunct blogs.

ack_complete
1 replies
18h36m

Afraid not, had to piece together a lot of it myself. There are lots of examples available for various components of varying quality -- you'll find some code examples that don't work well with high DPI or all of the sub-modes of a control.

Some controls like buttons, list boxes, list views are reasonably well behaved, especially when theming is turned off. Combo boxes and toolbars are more temperamental. Check boxes, scroll bars, menus, and message boxes require a lot of custom painting work.

MikeTV
0 replies
18h21m

Would you mind sending me an email (address in profile)? I'd love to pick your brain about some of the trickier ones I'm running into.

davee
0 replies
28m

I have a reasonably complete implementation of dark mode in my open source application, Explorer++. It uses the standard Win32 controls and applies a variety of strategies to get something that looks more-or-less cohesive when dark mode is enabled. ThemeManager.cpp[0] contains the bulk of the functionality. It could be useful as a reference for how you might create a dark version of a standard Win32 control.

[0] https://github.com/derceg/explorerplusplus/blob/4bad3ab95d87...

fleabitdev
5 replies
22h11m

Unlike Windows, Apple and Android have managed to publish modern UI libraries for their own platforms - but in both cases, this involved migrating the whole platform to a new programming language (Swift and Kotlin, respectively). If I remember right, C# also has a few features which were only added to make Windows Forms and WPF more ergonomic.

I'm starting to suspect that general-purpose languages just aren't flexible enough to keep up with changing fashions in UI development. Whenever somebody comes up with a new UI paradigm, you're not going to be able to take full advantage of it until somebody designs a new programming language with that paradigm in mind.

If so, this might explain why the Windows team keeps pushing new desktop UI libraries, only to abandon them within a few years - they just don't have the willingness or resources to migrate away from C# and C++, and so the quality of their UI libraries is stuck in 2006.

mike_hearn
2 replies
21h23m

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

fleabitdev
1 replies
20h29m

You're right that reactive UI is a poor fit for most languages (especially JavaScript!), but I think the problem is more general than that.

Good UI architecture needs some convenient and efficient way to propagate state changes between different parts of the UI framework [0]. This requirement sits in an awkward place, halfway between imperative programming and functional programming. It just isn't in the day-to-day vocabulary of any mainstream language, not even modern imperative languages which have a bit of functional programming mixed in.

I don't think OOP is any better at fulfilling this requirement. Being able to offload half of your program into a visual editor is nice, but it's cold comfort if the other half of your program ends up being a tangled mess of callbacks and data binding.

[0]: https://raphlinus.github.io/ui/druid/2019/11/22/reactive-ui....

skydhash
0 replies
19h36m

We already have a solution for most UI presented in this paper [1]. Functional programming let you represent the solution in a much nicer way after you've hidden the oop/imperative machinery away. But it's a complete package where the declarative part is only the shell. The UI part of any application should be considered as an external module, (like the data access layer) and the code architecture should reflect this. In an extreme way, if you can't create a telnet interface to you GUI software, that means your interface is already too coupled to the rest of the code.

[1]: https://dl.acm.org/doi/10.1145/62402.62404

wiseowise
0 replies
21h10m

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

pjmlp
0 replies
20h29m

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

ZoomZoomZoom
5 replies
20h59m

uses native Win32 components and offers no styling options

It's a feature.

Custom styling should be considered a hostile pattern in most cases, except in highly specialized software with workflows dependent on prior user experience, such as DAWs.

zigzag312
2 replies
6h14m

Custom styling should be considered a hostile pattern in most cases

Why? Almost every website has custom styling and yet it doesn't seem to inhibit users from using them.

Good UI/UX patterns seems to be universal. As consistency is part of good UI/UX there are things that should be consistent with the underlying platform. But consistency with the platform is not equally important for all things. For some things, like window management, it's much more crucial, that it is for other things, like roundness of buttons.

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

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

bux93
1 replies
3h41m

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

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

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

zigzag312
0 replies
26m

There's a lot of A/B testing going on on the web.

Buttons shouldn't be round in the first place.

Is there any data available to back this up?

Modern UIs are not perfect by any means, but from what I remember, those old UIs were not great either... even worse in terms of UX on average.

While consistency is important, placing it above all else, leads to suboptimal UX and bland UIs. How many times did you hear people raving about how great is the UI of an app build with a generic form builder?

ozim
0 replies
19h58m

Yes full agreement from me.

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

eXpl0it3r
0 replies
5h45m

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

kosolam
4 replies
23h12m

How about gtk?

talldayo
2 replies
23h10m

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.

tored
0 replies
10h44m

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.

ho_schi
0 replies
23h2m

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.

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

redox99
0 replies
21h50m

GTK programs look very out of place in Windows.

wolpoli
3 replies
13h26m

The result should be a single .exe file with no or minimal dependencies and a size of less than 40MB

Computers come with a modern browser now. Instead of a .exe file, could it be, let's say, a single .html file with inlined image/css/javascript?

wudangmonk
0 replies
11h34m

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

athanagor2
0 replies
12h31m

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

squarefoot
3 replies
17h14m

"Writing GUI apps for Windows is painful"

Until you discover Delphi/Lazarus.

pjmlp
1 replies
7h58m

And C++ Builder as well.

squarefoot
0 replies
3h33m

Yes of course. Extending the Lazarus ecosystem to support more languages would be a killer feature.

cookiengineer
0 replies
7h24m

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

Then I would never use anything else ever again.

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

openrisk
3 replies
5h7m

One would think that after three decades of the windows metaphor and billions of man-hours writing such applications, writing GUI apps (for any platform) would be a much more pleasant experience?

One could imagine a framework that would absorb all this historical know-how and turn GUI app development into a zero marginal cost exercise (fast, functional, cheap and maybe even pleasant) but who would push for this and why?

Maybe its a case of somebody not learning a lesson when their economic interest depends on not learning it?The overview of existing frameworks (including browser/webview based) suggests there is a sort of stagnating stalemate that feels sub-par but probably works just fine for those who have any leverage over the status-quo.

shortrounddev2
2 replies
4h8m

There is a UI framework which is fast, functional, cheap, and (depending on your personality) pleasant: the web browser.

HTML and CSS are go-to strategies not just because the web is the target platform for probably most if not almost all user interfacing software these days, but because HTML and CSS are very forgiving. Native UI frameworks are written by software engineers who demand type safety and XAML-like features which convert declarative syntax into imperative/object-oriented C#. The truth is that the vast majority of people who work on user interfaces are not the kinds of software engineers who enjoy this; HTML's model of creating arbitrary blobs of flexible dom nodes (and then using javascript to handle user interactions) is a lot more pleasant than getting compilation error after compilation error in XAML and having to google how the hell you display a set of items in a ListBox, only to have to filter through 4 or 5 different slight variations in the proper types between WinUI 3, WPF, UWP, and Maui.

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

openrisk
1 replies
3h43m

There is certainly a strong case for the web platform as an all-weather gui platform but on actual mobile and desktops of here and now it is not a no-brainer choice. Its document oriented nature fits some use cases better than others. Not to mention that with the near exclusive focus on (incompatible) javascript frameworks it is not exactly clear even what "html" means...

shortrounddev2
0 replies
3h36m

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

ceeam
3 replies
22h26m

Who's going to tell him about C++ Builder (Embarcadero)?

RachelF
1 replies
22h10m

No one wants to talk about it or Delphi anymore.

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

boznz
0 replies
21h35m

This. But flares are still waiting to come back in this case. To get my foot in the door writing windows GUI programs I often have to obfuscate the fact I am using Delphi (don't ask, don't tell) or work with clients without big IT departments.

Disclaimer - No clients were ever injured during this experiment.

wiseowise
0 replies
21h9m

Wouldn’t that be excluded due to cost?

pugworthy
2 replies
22h44m

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.

chipdart
1 replies
22h31m

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.

pjmlp
0 replies
20h31m

WinUI support for C++ is a travel back to the days of writing COM in Visual C++ 6.0 with ATL, only for a special bread of developers.

pshirshov
2 replies
1h26m

I had a similar struggle. I needed a truly cross-platform (Windows, Linux/Wayland, Mac, iOS, Android) GUI toolkit with rich controls library and reasonable theming. In fact, the only good option is QT and it's very hard to be productive with C++, it still lacks even basic features, like type deconstruction and ADTs/GADTs with exhaustiveness checks. QT bindings for other languages aren't mature enough.

Apart from QT, there is Avalonia, which is full of bugs. Linux support is remarkably bad.

Also there is Kotlin/Compose Multiplatform. It lacks good documentation, advanced controls and still full of bugs.

I was unable to find any good controls library for JS/TS, even paid ones (like Telerik and others) are pretty messy. So, Electron, Capacitor, React Native - they all assume a non-trivial effort to be put into even a very basic app.

Flutter feels extremely immature, and the strange popularity of global singletons makes it extremely hard to navigate even small codebases.

kergonath
1 replies
1h8m

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

pshirshov
0 replies
54m

If I go with C++, I'll take QT, which has lot more extensive controls library and in fact allows me to be more productive than wxw.

Unfortunately, the main productivity limiter is C++ and that's something I really want to avoid. I've been writing C++ professionally for about 8 years so I think I can make such statements.

pan69
2 replies
22h52m

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.

Microsoft has developed VSCode with Electron.

https://www.electronjs.org/

chipdart
1 replies
22h34m

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

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

pjmlp
0 replies
7h54m

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.

neonsunset
2 replies
22h22m

The author would have been served extremely well by AvaloniaUI with NativeAOT target if they were willing to drop their assumptions regarding C# that are no longer true. (I wonder how well Uno Platform fares in comparison? It targets native controls first and foremost but is supposedly NativeAOT compatible too)

achr2
0 replies
21h22m

A second recommendation for Avalonia. It deserves the acclaim.

Kuraj
0 replies
20h59m

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

mattgreenrocks
2 replies
22h58m

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.

throwaway2037
1 replies
13h6m

I agree with the sentiment of your post.

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

mattgreenrocks
0 replies
7h28m

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.

bonestamp2
2 replies
17h32m

Writing the GUI part of the program should not take more time than the actual functionality

I don't understand why this is a rule. I mean, I don't know what the author is trying to build, but in general the GUI is the part that the users spends all of their time interacting with. I don't see why it would be a problem if a little more time was spent there.

shortrounddev2
0 replies
4h6m

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

mshekow
0 replies
13h18m

I agree.

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

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

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

the__alchemist
1 replies
20h46m

I've been using EGUI to write GUI programs. Works nicely and runs on both Linux and Windows without notable differences. (I haven't tried Mac, but it presumably will work there as well without changes). Small binaries (a few Mb), and can integrate with maps, 3D rendering etc.

ModernMech
0 replies
15h0m

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

synergy20
1 replies
22h6m

write a cross platform GUI is even more painful.

It's pretty much either paying for Qt or use the bloated Electron.js. Looks like the latter won the market.

I failed to see other practical options, flutter was an option, but its strength is not on desktop so far.

duckywise
0 replies
18h59m

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

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

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

rovingeye
1 replies
22h52m

Win32 + WebView2

tored
0 replies
7h35m

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

lowleveldesign
1 replies
21h58m

Apps developed for the modern (open-source) version of .NET may be compiled to a native code (NativeAOT). Some time ago, I tried AOT on a simple WinForms project and it worked. Unfortunately, functions using COM APIs are not yet supported (as they rely on reflection). There is an ongoing effort to fix this problem: https://github.com/dotnet/winforms/issues/4649

armchair_expert
0 replies
3h12m

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.

jacinabox
1 replies
3h13m

Actually a lot of people are saying that Linux is the best platform for developing GUIs.

Andrex
0 replies
2h56m

Every OS/environment should have a GNOME Builder equivalent.

graynk
1 replies
11h58m

Writing GUI apps for anything is painful, if we’re being honest. To this day I haven‘t seen a single good GUI framework for any of the platforms that I‘ve tried. Flutter feels nice though

gyomu
0 replies
11h50m

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

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

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

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

dmitrygr
1 replies
22h13m

“Stylized”

Let me stop you right there. No.

Leave the OS to style controls how it does, for consistency. There is no reason to be inconsistent. This is not 1994 and you’re not writing a warez keygen

Kuraj
0 replies
20h58m

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

dgellow
1 replies
3h31m

WPF is still a perfectly viable solution

The issue is that with bundling the .dll, it would still mean it being extracted somewhere and writing additional code for the P/Invoke to work, and C++/CLI gets compiled to .NET IL code, in other words, you can open the resulting app in dnSpy and see the C++ code translated to C# equivalent (which is not what I want, I want native code).

I don’t understand how that makes WPF a non-viable solution. The author seems to have pretty strong feeling that it should absolutely be native code, but it’s not clear why

scherlock
0 replies
3h16m

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

daemin
1 replies
10h20m

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

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

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

rubymamis
0 replies
4h54m

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

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

boffinAudio
1 replies
10h56m

I just write GUI's in tkinter (python), build a single .exe with nuitka, and interface with generalized application functionality either as a .dll or python module ..

tkinter may not be the sexiest way to do things, but its definitely productive in terms of the code-compile-distribute methodology, and it is very easy to wire up to a generalized 'daemon'-style abstraction, where the app logic is implemented as a daemon, sent application commands over a well-greased socket.

With this architecture, I no longer care that its Windows underneath - this is just another platform target - and can easily use either MacOS or Linux as the development environment, needing only to test on Windows, ultimately.

Anything beyond the sphere offered by tkinter is just less appealing. If I have to start treating a platform target in any kind of 'special' way, I just lose interest in that target, as a whole - however, from a UI perspective, Windows tkinter support hasn't been that bad, and generally keeps up fine.

(Disclaimer: if I really need performance, I also use the JUCE framework for my needs - even though its an audio-centric framework, you can build GUI apps with it just as well, and its also a cross-platform way to do things in pure C++ ..)

neonsunset
0 replies
7h44m

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

bambax
1 replies
11h27m

LuaRT (https://luart.org/) came up here a couple of months ago; would it meet the requirements?

JourneyJourney
0 replies
9h31m

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

anthk
1 replies
22h43m

Lazarus and Free Pascal might work here.

Androth
0 replies
16h8m

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

account42
1 replies
2h11m

Writing the GUI part of the program should not take more time than the actual functionality

That's rarely a reasonable expectation. Good usability is hard work.

I figured out that for simple apps there is simply nothing better suited than Dear ImGui.

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

ropejumper
0 replies
2h0m

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

Do you have any actual real criticism?

JodieBenitez
1 replies
22h39m

I don't do a lot of desktop apps but for simple GUI apps I've been using Python and Pywebview, with packaging left to Pyinstaller. The main reason is that I get to reuse the python/javascript/css libs that I know, and it's easily portable. I'm sure a native app uses less memory and cpu but frankly what I get with this combination is not that resource hungry. In fact, anytime something goes south it's my fault for using poor algos. Also, there are tons of great GUI libs and web components.

blep-arsh
0 replies
19h46m

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

xbar
0 replies
13h18m

For someone who demands so much of other people's open source, the author is quite unwilling to open source their solution.

wiseowise
0 replies
21h18m

Did someone suggest Flutter yet?

torginus
0 replies
23h1m

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.

thefz
0 replies
21h48m

Nope, not at all. Winforms is still actively maintained and sports native advanced features like MVVM and async support. And winforms is not even the only option.

I disagree with the entire aeticle.

theanonymousone
0 replies
22h44m

Writing GUI apps is painful, and being probably the most thankless area in Software engineering doesn't help either.

syngrog66
0 replies
15h52m

ah, the intersection of 2 anti-patterns: GUIs and MS Windows. lol

symisc_devel
0 replies
22h1m

Open source GUI libraries are lacking behind the gate locked, closed ones like Adobe. Even Macromedia UI back in the days 20 years ago looks way more appealing and polished than the current open source offering. The only polished open source UI in my opinion is Blender but apparently they have their own rendering engine built from scratch just like Adobe.

smittywerben
0 replies
14h22m

Microsoft: Here are cool windows for Windows.

Microsoft: Oh, yeah, to use it, you'll need to deploy it with the Microsoft Store.

slackr
0 replies
22h46m

Tried Decker?

skrrtww
0 replies
22h28m

What are the issues the author alludes to about AppX packages sucking? Looks like the new Fluent stuff wants you to use those. Curious to know what pain points exist there.

shrimp_emoji
0 replies
19h25m

Writing anything for Windows is painful. Writing it on Windows is even painfuler.

robertlagrant
0 replies
6h53m

Tauri[0] is another HTML/CSS/JS-converter that generates small binaries by relying on the presence of WebView. Works pretty well.

[0] https://tauri.app

renegat0x0
0 replies
6h30m

The requirements are strict.

For myself I rarely write app. Most often I self-host programs. GUI is managed by a browser.

ramesh31
0 replies
1h52m

Writing the GUI part of the program should not take more time than the actual functionality

I can't stand this mentality. The GUI is your functionality. The rest as far as the user is concerned may as well be pixies and fairy dust. Treating UI as an afterthought is why we've ended up with so much nightmarish crap these days.

philipwhiuk
0 replies
22h33m

There's a reason a lot of stuff is Electron.

p0w3n3d
0 replies
6h46m

I've been a strong lover of Qt, but I've just undestood that one cannot statically link it. Tbh it's never been the case in my situation, usually writing in PySide bindings which will never link dll/so libraries, however in certain situations this would get really expensive, if static linking would be required.

   I am writing this article while it’s 32°C inside my room.
It took a horrendous heat to make a programmer find the best GUI library, but it was worth it! 500KB for imgui? Seriously? I remember Inno Setup creator saying that we was compiling his 'boot' application (to reduce size, because it was glued as a prefix to a zip file) in Delphi 2...

okasaki
0 replies
8h31m

Problem: When linking dynamically, there are a myriad of different .dlls required to run the app, totaling over 40MB.

Is 40MB a lot nowadays? Eg the argocd cli is 155MB, and that's just a relatively simple cli app that as far as I know just calls a remote api.

Welcome to bloatworld I guess.

mrcsharp
0 replies
4h37m

I don't see Avalonia[1] mentioned here. Maybe that would work? It has AOT support too so should help with distribution and file size.

[1] https://www.avaloniaui.net/

mmargerum
0 replies
8h9m

Delphi is the superlative windows desktop development tool. It does support styling and just about anything else you would want. There is a free alternative in Lazarus but I don’t know if it supports styling

johnea
0 replies
19h49m

Qt is the hero

jll29
0 replies
22h17m

The amount of bloat everywhere today is simply disgusting; just because my group server has 1 TB of RAM isn't a justification for letting a "hello world" app grow to more than 50 kB, GUI or not.

Yes, productivity is more important than squeezing out the last bit nowadays, but that the poster couldn't get his 40 MB limit satisfied shames the whole software industry. He should get a simple (i.e., half a dozen menus, dialogs, windows) GUI app done in 400 kB (it was possible in the past).

jerf
0 replies
3h59m

When people ask "why isn't there an awesome native widget set for my favorite language?" I have often said that GUIs are way, way, way harder than you think. It's easy to create a toolkit for your exact use case, but to create a toolkit that fits everyone's use cases to some degree is vastly, vastly larger than merely creating a programming language and a reasonable standard library. Vastly.

This is a great example of why. A small set of reasonable requirements and already almost all the options on what is probably the best-endowed OS for toolkits are almost all disqualified, and what did fit was an odd solution that won't work for a lot of other use cases. It isn't that these are unreasonable requests per se, it is that this is how this space works. Everybody has weird requirements of some sort, pretty much all the time, and getting even reasonable coverage is a huge, huge project.

hgs3
0 replies
14h28m

It would require me to write a custom paint function for every single control, which would take so much time I could raise a family in the meantime.

Implementing a custom paint routine is how you do theming in many UI toolkits. I get the impression the author is looking for a toolkit with declarative theming, like CSS.

hermitcrab
0 replies
20h44m

Alternatively, you can buy a commercial [Qt] license for several thousand dollars.

There is a small business option that is cheaper. But probably still not appropriate for this project.

grahar64
0 replies
22h59m

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.

gchokov
0 replies
6h51m

It was a breeze, back in the RAD / Delphi days..

gavinhoward
0 replies
22h25m

I have ideas about writing a GUI framework [1], but why in the world would I spend the time to make it up to the author's standards unless someone was paying me?

GUIs are a lot of work. People should be more willing to pay for work like that. Wanting everything free is one reason Big Tech has so much control.

[1]: https://gavinhoward.com/2024/05/a-new-architecture-for-a-gui...

garaetjjte
0 replies
21h56m

The issue is that with bundling the .dll, it would still mean it being extracted somewhere

Hmm, this got me thinking about stuffing native code into CLR image. If you would just include additional executable code sections into PE, would loader map them normally? Or presence of IMAGE_DIRECTORY_ENTRY_COMHEADER would stop it from mapping native code? If so, maybe you could remove that header and manually do pre-XP style initialization, by calling _CorExeMain from imported mscoree.dll. Though you would need to somehow trick it into locating COMHEADER that we removed.

Or maybe I'm overthinking this and MS already supports that? https://learn.microsoft.com/en-us/cpp/dotnet/mixed-native-an...

fuzztester
0 replies
13h48m

Did they try JUCE?

firebot
0 replies
20h48m

There's tools to pack dependencies into a single executable, that then extracts those dependencies, as necessary, upon execution.

dusted
0 replies
11h52m

"Problem: It is extremely hard to stylize native Win32 controls." No. Don't style them. Let the users settings dictate how your app looks. This is the correct way.

donatj
0 replies
6h45m

Writing the GUI part of the program should not take more time than the actual functionality

Oh man, I wish. No such tool exists. Adding a GUI to anything almost always at minimum triples the complexity.

dkersten
0 replies
12h35m

Dear ImGui is nice but beyond basic styling, it’s not exactly quick and easy to style. It also lacks any kind of accessibility features, which is fine when you’re making tools for games or similar (ie highly visual tools), but if you’re making anything meant for a wider audience, you really should use something with solid accessibility support so stuff like screen readers work.

djbusby
0 replies
21h39m

I don't see any mention of WinAmp yet. That app really whipped the llamas ass when it came to styling. And was super easy to create custom skins.

I'm all-on-board with look like the OS/platform but also, here's and example of custom styling done well.

cryptica
0 replies
20h20m

One thing I learned about the software industry is that a lot of the tools we use are objectively horrible, but it doesn't matter because somehow big tech manages to shove it in our faces anyway.

Also, the inverse that really good software tools often don't see the light of day is also true. It really doesn't matter if some tool is good or bad for adoption. What matters is; does it have the backing of big tech? It shows that tech media is completely monopolized.

cerrorism
0 replies
11h59m

I would like to show my appreciation to the author of this blog, although a lot of comments here show otherwise, as the restrictions the author has involved here are considered as "unrealistic" or "unreasonable".

Whenever an article is trying to compare several options, it is very important to know beforehand what the author is trying to achieve, and what the restrictions are. And in this blog, the author has clearly stated that the restrictions are to develop a GUI within 40MB and should be easy styling. No one should judge the author for the restrictions, as it may be from the author's specific needs, or directly come from the client's requirements. The clear restrictions are also very helpful for readers like me to understand the trade-offs the author has made, which is not something that I have to do myself, but I can definitely learn from the author's experience. If I am in a similar situation, or even with different restrictions and need to make a different trade-off, the author's experience can still be very helpful for me.

Just want to call out that it is not a fair ask for a blog post to exhaustively compare all the options, as it is very time-consuming for even a paying job. We learnt the specific restrictions that the author is facing to, and we learnt the author's experience with the options that the author has tried. That is already a lot of value that the author has provided to us, and I would like to thank the author for that.

canistel
0 replies
22h49m

Native widgets which used to be wxWidgets' strong point, is now its Achilles heel? It is saddening, but the world moves on I guess.

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

boxed
0 replies
9h45m

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

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

bonestamp2
0 replies
17h24m

I work on several enterprise apps that are .NET but the GUI is a webcontainer with a web app. Unless there is something particularly high performance happening in the GUI, this works really well for several reasons:

1. We can update the gui without the user installing an update.

2. Lots of great web ui libraries, designers, and developers to make it look great.

3. Relatively lightweight

bigmattystyles
0 replies
1h49m

I'm a fan of a self hosted web service bound only to localhost, then you serve a HTML with all the bells and whistles from that web service. I think they used to call it OWIN. I guess the major downside is that you might get a localhost cert warning if you don't install a self-signed cert and a root cert in the PC's cert store (which yes, yikes)

avsteele
0 replies
20h33m

I tried to write a windows App recently (maybe to put in the windows store). I gave up when ...

- Tried to wade through the mess of different frameworks. Some are abandoned, they all have different feature sets etc...

- I found that I could not have anything other than FullTrust (all permissions) if my app wanted to use the/live in the system tray.

- You can't set the size of the window to match the content. You can set a size, sort of, but the min is 500x500 AND it will remember what the user's last size was so if they e.g. maximize it will be the next time its opened regardless of the program settings. In order to do this simple thing I would have to write it as a WPF app with a installer (which as of 2023 can go on the Windows Store)

airstrike
0 replies
14h17m

Shoutout to the Rust library `iced` which is cross-platform, amazing, and can do anything you need it to at blazing fast speed and low memory footprint: https://github.com/iced-rs/iced

Log_out_
0 replies
2h8m

Don't ,don't say that,every time you say that windows gains another guiframework that precents fixes to winforms,the only one they support..

IshKebab
0 replies
22h23m

Frankly Qt is the only sane option. Just give up on the "single static exe" requirement. Your users will have to unzip a zip. Hardly a big deal. Certainly not worth switching your entire stack to something vastly inferior for.

HumblyTossed
0 replies
5h1m

On the rare occasion I find myself needing to write a windows gui, I just use winforms. I don't have to muck about with XML nonsense and it just works.

FactKnower69
0 replies
2h3m

WinUI

modern Windows components

I swear to God if I ever downloaded a piece of open source software from GitHub, opened it, and saw the deformed Windows 8 Metro UI gawping back at me, I would do everything in my power to wipe the blighted individual responsible from the face of the fucking Earth

Dwedit
0 replies
21h49m

WX Widgets still exists.

ChicagoDave
0 replies
12h26m

Wouldn’t Electron solve this problem?

Build a web app and use Google V8 with your c++ code.