Writing GUI apps for Windows is painful

2024-06-3018:53468561localhost

Why trying to write GUI apps for Windows causes me physical pain

For the past few days, I have been trying to find a library that would allow me to write programs with a GUI in C++. My requirements were pretty straightforward:

  • Only Windows support required
  • Commercial use allowed
  • Easy styling, including dark mode
  • The result should be a single .exe file with no or minimal dependencies and a size of less than 40MB
  • Writing the GUI part of the program should not take more time than the actual functionality

WinUI 3

At first glance, it looks like an excellent choice. It allows you to use modern Windows components while also letting you customize the styling colors. For design, you can use XAML, which is super easy to grasp, or you can just use the Visual Studio designer directly.

screenshot

(ImGui AppKit compiled app size)

The compiled program has only 500KB in size and does not require the installation of anything, not even VC++ redistributables if you statically link MFC into it.

Note: I am writing this article while it’s 32°C inside my room. As a fellow European, I do not have air conditioning. Please forgive any grammatical errors or poorly structured sentences.


Read the original article

Comments

  • By Aurornis 2024-06-3019:2913 reply

    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.

    • By eschaton 2024-06-3020:083 reply

      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.

      • By barrkel 2024-06-3021:003 reply

        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.

        • By klabb3 2024-07-0110:542 reply

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

          • By wongarsu 2024-07-0113:581 reply

            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.

            • By MBCook 2024-07-0115:401 reply

              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.

              • By flyingpenguin 2024-07-0119:262 reply

                Depends on the app size also.

                Is your app as large and important as the OS of the device (Chrome/facebook/etc...) you should probably have similar language across devices.

                Is your app very large but not that large? (Slack/teams come to mind) I think you can go either way.

                If you are smaller than that (hint: you are) then you should comply with the design language of the platform, even if that means somewhat large changes such as moving buttons from the left to the right. The likelihood that users are constantly using your app on a iphone and android is really low.

                • By MBCook 2024-07-0121:15

                  I disagree. I think the only apps where a custom UI make sense are games and I’m willing to accept highly specialized business apps that have their own conventions. Thinks like Blender, AutoCad, Logic, etc.

                  I’d still like to see them try to match a little, but they’re specialized enough I get that may be a better path.

                  Chrome? Facebook? Slack? Teams? No.

                  I’m not saying things need to look like MyFirstWin32App built with VB6 in 20 minutes.

                  But use the system controls and conventions. Custom colors and layouts can be fine. But if you want to make your own UI toolkit then make your own OS too and leave my computer alone.

                • By kergonath 2024-07-0317:22

                  > Is your app as large and important as the OS of the device (Chrome/facebook/etc...) you should probably have similar language across devices.

                  No app is more important than the OS, and certainly not Facebook (which has no business being an app in the first place). I made a choice when I got the OS, and I like developers respecting it and not chase the fad of the day with poor approximations of the native widgets (text fields that do not support standard shortcuts, buttons that do not behave as they should, labels that do not support accessibility features, the list could go on). Even huge apps like Photoshop or Office get this wrong everywhere.

                  I definitely agree on the default (use the native toolkit), but there are no applications big enough to get their own behaviour. Open Source or hobby applications get a pass if the UI is a bit wonky, but that’s about it.

          • By ToucanLoucan 2024-07-0114:02

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

        • By therein 2024-07-0110:321 reply

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

          Even Microsoft struggles with that.

          • By pc86 2024-07-0113:451 reply

            Only because they change the system theme every 45 minutes.

            • By ToucanLoucan 2024-07-0114:11

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

        • By threatofrain 2024-07-0117:081 reply

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

          • By Arrath 2024-07-0121:44

            I, for one, miss customized installers. We've kind of lost out on those what with the move to digital distribution.

            Gone are the days of my friend accidentally having his volume cranked when he inserted the Red Alert 2 disc, not knowing it would blast out "WARINING! Military Software Detected!"

      • By cageface 2024-07-013:402 reply

        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.

        • By bobajeff 2024-07-0114:131 reply

          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.

          • By cageface 2024-07-0114:43

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

        • By throwaway2037 2024-07-015:302 reply

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

          • By biztos 2024-07-017:281 reply

            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.

            • By throwaway2037 2024-07-018:052 reply

              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.

              • By biztos 2024-07-0110:291 reply

                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!

                • By cageface 2024-07-0110:572 reply

                  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.

                  • By throwaway2037 2024-07-031:07

                        > If you really want native look and feel then really your only choice is to use the native toolkits.
                    
                    What about Qt?

                  • By biztos 2024-07-0112:291 reply

                    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.

                    • By cageface 2024-07-0113:191 reply

                      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.

                      • By mst 2024-07-0116:001 reply

                        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.

                        • By cageface 2024-07-020:23

                          I don't think it it's a technical issue. On a technical level Flutter is mostly great. But Google has been doing aggressive cost cutting lately and not having Flutter in use in that many apps makes it more vulnerable.

              • By cageface 2024-07-019:041 reply

                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.

                • By biztos 2024-07-0110:331 reply

                  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.

                  • By cageface 2024-07-0110:59

                    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

          • By cageface 2024-07-015:421 reply

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

            • By superb_dev 2024-07-017:28

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

      • By vintagedave 2024-07-0115:10

        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.

    • By elpocko 2024-06-3019:524 reply

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

      • By userbinator 2024-06-3020:261 reply

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

        • By delta_p_delta_x 2024-07-014:572 reply

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

          • By summerlight 2024-07-0111:03

            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.

          • By spookie 2024-07-018:551 reply

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

      • By ranger_danger 2024-07-010:452 reply

        ImHex uses it for the entire UI

      • By bun_terminator 2024-06-3020:021 reply

        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.

        • By fuzztester 2024-07-0115:002 reply

          Due to what reasons does imgui offer incredible development speed?

          • By bun_terminator 2024-07-0116:101 reply

            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.

          • By masfoobar 2024-07-0311:43

            To add to this, I find it easier to have a simple while loop that renders the screen, fetching variable data on-the-fly, etc. It is rather pleasing to the eye to understand the layout with IM interfaces, etc.

            Comparing this to (something like) WPF, you create XAML files, with either or combination of ViewModels and back-end code to "bind" and can get complicated quickly. I guess the only exception to this is if you have commited to WPF non-stop for many months. However, with IM interfaces, its easy to get going (imo)

      • By throwaway2037 2024-07-015:311 reply

            > proper keyboard support
        
        Specifically, what does this mean?

        • By TJSomething 2024-07-016:421 reply

          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.

          • By throwaway2037 2024-07-018:03

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

    • By rty32 2024-07-014:223 reply

      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.

      • By beagle3 2024-07-017:302 reply

        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.

        • By ClumsyPilot 2024-07-0113:12

          > 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

        • By rfoo 2024-07-018:302 reply

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

          • By beagle3 2024-07-0111:36

            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.

          • By rlinge 2024-07-021:49

            There's another way to build a 150KB or less executable today. Mime is less than 90KB, have a look at https://webd.cf/webd/ It's a web file manager.

      • By abareplace 2024-07-0112:53

        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.

      • By alok-g 2024-07-0112:471 reply

        Winamp comes to mind as a counter example.

        • By hermitdev 2024-07-0116:211 reply

          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.

          • By alok-g 2024-07-0116:51

            +1.

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

    • By wkat4242 2024-07-011:14

      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.

    • By pc86 2024-07-0113:431 reply

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

      • By throw__away7391 2024-07-0116:351 reply

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

        • By naitgacem 2024-07-0119:10

          I might understand polished, but no issues sounds odd. What about the abysmal performance? Also most folks building things do not have the resources that Microsoft has, so I believe VSCode is not a good represantative of most Electron software.

    • By EasyMark 2024-06-3022:321 reply

      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)

      • By smackeyacky 2024-06-3022:484 reply

        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.

        • By wvenable 2024-07-014:51

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

        • By jen20 2024-06-3023:43

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

        • By alkonaut 2024-07-019:39

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

        • By ivm 2024-07-013:283 reply

          WinUI 3 is the default for Windows-only applications

          • By pjmlp 2024-07-0110:051 reply

            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.

            • By CrimsonCape 2024-07-0118:10

              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?

          • By LordDragonfang 2024-07-014:34

            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.

    • By jocoda 2024-07-015:171 reply

      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.

      • By cratermoon 2024-07-016:23

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

    • By chipdart 2024-06-3019:431 reply

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

      • By Shorel 2024-06-3019:592 reply

        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.

        • By deutschepost 2024-06-3020:022 reply

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

          • By singpolyma3 2024-06-3021:535 reply

            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.

            • By cesarb 2024-07-0116:46

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

            • By bla3 2024-07-015:14

              The linked post does mention that:

              > or distribute object files for recompilation

            • By Wowfunhappy 2024-07-014:401 reply

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

            • By leni536 2024-07-0110:45

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

            • By alok-g 2024-07-0112:532 reply

              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.

              • By singpolyma3 2024-07-020:31

                I don't see why not. So long as the LGPL part can be modified and replaced, you're good.

                I am not a lawyer.

              • By saagarjha 2024-07-020:541 reply

                I mean, if you're willing to do that why not just dynamically link?

                • By alok-g 2024-07-0216:151 reply

                  The OP article is saying that static linking leads to size reduction. That's why asking.

                  • By saagarjha 2024-07-0221:471 reply

                    You’re not getting a size reduction if you maintain a library boundary, though. What you’re doing is isomorphic to dynamically linking except the app code is in the library and the library code is in the main binary.

                    • By alok-g 2024-07-032:45

                      Ok. I understood. Thanks for explaining.

          • By jjmarr 2024-06-3020:181 reply

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

            The LGPL is working as intended.

            • By deutschepost 2024-06-3020:512 reply

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

              • By EasyMark 2024-06-3022:342 reply

                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.

                • By josefx 2024-07-017:071 reply

                  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.

                  • By jimbobthrowawy 2024-07-020:00

                    Does using something like APE by jart work? It's a single executable that's also a zipfile. (I assume a replaceable .dll inside the archive is LGPL compliant) I know it's a bit of a tangent, but on platforms like macos the "apps" are all directories with the .app extension, and that doesn't seem to cause issues.

                • By ranger_danger 2024-07-010:461 reply

                  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.

                  • By riffraff 2024-07-015:251 reply

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

                    • By Kwpolska 2024-07-016:09

                      .7z recently got native support.

              • By TheCoelacanth 2024-07-0114:09

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

        • By chipdart 2024-06-3020:001 reply

          CopperSpice is LGPL, not GPL.

          It's not a problem.

          • By alok-g 2024-07-0112:541 reply

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

            • By Liquid_Fire 2024-07-0114:191 reply

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

              • By alok-g 2024-07-0114:331 reply

                Some parts of Qt are GPL only.

                • By Liquid_Fire 2024-07-0115:12

                  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.

    • By dokka 2024-06-3020:151 reply

      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.

      • By fuzztester 2024-07-014:194 reply

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

        • By WorldMaker 2024-07-0115:55

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

        • By EnigmaFlare 2024-07-019:40

          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.

        • By throwaway2037 2024-07-015:35

          .NET 4.8 is default in Win10/11 now.

        • By fuzztester 2024-07-021:08

          Thanks, guys.

    • By ClumsyPilot 2024-07-0113:061 reply

      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.

    • By slaymaker1907 2024-07-0116:431 reply

      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.

      • By dgellow 2024-07-0116:46

        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

    • By PaulHoule 2024-07-0115:071 reply

      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.

      • By mst 2024-07-0116:05

        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.

    • By spintin 2024-07-0114:29

      [dead]

  • By Lariscus 2024-06-3022:424 reply

    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.

    • By hsn915 2024-07-0110:302 reply

      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.

      • By Lariscus 2024-07-0111:173 reply

        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.

        • By daemin 2024-07-0111:231 reply

          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.

          • By Lariscus 2024-07-0112:541 reply

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

            • By daemin 2024-07-0113:021 reply

              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.

              • By Lariscus 2024-07-0113:342 reply

                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.

                • By pantulis 2024-07-0116:15

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

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

                • By CSSer 2024-07-0116:26

                  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.

        • By hsn915 2024-07-0115:57

          Your take is very weird.

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

        • By dvngnt_ 2024-07-0116:45

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

      • By daemin 2024-07-0111:181 reply

        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.

        • By jnhzubh 2024-07-0115:571 reply

          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

          • By hermitdev 2024-07-0118:19

            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.

    • By madduci 2024-07-016:48

      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.

    • By kelnos 2024-07-015:551 reply

      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.

      • By eptcyka 2024-07-0112:311 reply

        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.

        • By jnhzubh 2024-07-0116:151 reply

          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

          • By mavamaarten 2024-07-0120:11

            Also trivially achievable by making an installer instead of shipping separate files. People are really used to that pattern.

    • By zer0zzz 2024-07-0117:131 reply

      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.

      • By Lariscus 2024-07-0216:001 reply

        Yes, closed source libraries are a pain to work with. This is why I like the GPL/Commercial dual licensing model. You can try it out for as long as you like, have full access to the source code and can even create commercial software for free. You are only required to pay for a license if you want to create closed source software. I consider this an absolutely fair deal, yet the blog author seems to take issue with that which is what I am criticizing.

        • By zer0zzz 2024-07-0217:121 reply

          That’s fair in theory, but it really feels that they’ve made it more difficult to find the open source version of Qt last I checked. I haven’t tried to use it in a while, but I recall last time I tried I just gave up.

          • By Lariscus 2024-07-0218:181 reply

            Unfortunately they do and they really try to scare you away with the GPL boogeyman. It is a fair criticism. I would recommend to ignore the installer entirely and rely on a package manger like vcpkg, conan, apt, or brew instead.

            You can find the manual installer here:

            https://www.qt.io/download-qt-installer-oss

            • By zer0zzz 2024-07-0423:24

              Yeah I should have just used brew. I was trying to find the package for Mac a while ago to see if I could write some swift bindings. I moved on to messing around with some other library for my experimentation.

  • By alkonaut 2024-06-3019:432 reply

    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.

    • By chipdart 2024-06-3019:463 reply

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

      • By smileybarry 2024-06-3022:262 reply

        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.

        • By whywhywhywhy 2024-07-0113:102 reply

          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.

          • By WorldMaker 2024-07-0116:07

            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.

          • By HumblyTossed 2024-07-0113:271 reply

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

            • By estebank 2024-07-0116:041 reply

              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.

              • By whywhywhywhy 2024-07-0215:02

                The OS presumably also knows where I should get it from as the same company hosts the installer as ships the OS. Yet IIRC the error is just an obtuse thing complaining a DLL isn't there and through googling and hopefully finding your way to Microsoft.com not some malware site you have to find the installer yourself.

                Mild annoyance for someone with 28 years Windows experience, complete roadblock or malware vector for someone who just wants to use a computer rather than understand a computer.

        • By neonsunset 2024-06-3023:193 reply

          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.

          • By pjc50 2024-07-018:42

            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.

          • By smileybarry 2024-07-010:071 reply

            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.

            • By neonsunset 2024-07-010:141 reply

              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.

              • By pjmlp 2024-07-0110:12

                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.

          • By pjmlp 2024-07-0110:10

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

      • By pjmlp 2024-06-3021:48

        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.

      • By mike_hearn 2024-06-3021:01

        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.

    • By vunderba 2024-06-3020:053 reply

      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.

      • By smileybarry 2024-06-3022:282 reply

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

        • By alkonaut 2024-06-3023:191 reply

          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.

          • By smileybarry 2024-07-010:08

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

        • By pjmlp 2024-07-0110:15

          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.

      • By delta_p_delta_x 2024-06-3020:111 reply

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

        • By alkonaut 2024-06-3023:20

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

      • By TheDudeMan 2024-07-016:00

        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.

HackerNews