45 ms·

Writing GUI apps for Windows is painful

• api 2y ago
  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.
  • MrMember 2y ago
    Say what you will about VB6 but it was stupid simple to get GUI apps up and running.
    • lylejantzi3rd 2y ago
      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 2y ago
        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.
  • Aurornis 2y ago
    > 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.
    • beart 2y ago
      > 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.
    • Closi 2y ago
      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.
      • kirubakaran 2y ago
        Your profile doesn't list your email, so I'm posting here... is this the paper you were looking for? https://depts.washington.edu/acelab/proj/dollar/index.html https://depts.washington.edu/acelab/proj/dollar/index.html Your original post for context: https://news.ycombinator.com/item?id=26152600 https://news.ycombinator.com/item?id=26152600
• popcalc 2y ago
  >As a fellow European, I do not have air conditioning. Is anything stopping the author from buying a heat pump?
  • tjoff 2y ago
    Usually, living in an apartment.
  • bpfrh 2y ago
    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%2Fglawindows.com%2Fwp-content%2Fuploads%2F2020%2F06%2F20200605fa.jpg&f=1&nofb=1&ipt=ff39470e46af04a485e76fa20bcb580636342c52267dee59621e2ba02643b74a&ipo=images https://external-content.duckduckgo.com/iu/?u=https%3A%2F%2F... edit: qualified the law statement
    • mdorazio 2y ago
      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.
      • gibsonpil 2y ago
        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.
        • bpfrh 2y ago
          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.
• kosolam 2y ago
  How about gtk?
  • talldayo 2y ago
    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.
    • ho_schi 2y ago
      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 https://www.msys2.org Meson: https://mesonbuild.com 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 https://github.com/dankamongmen/notcurses. Demo of Ncurses (For the lulz): https://www.youtube.com/watch?v=dcjkezf1ARY https://www.youtube.com/watch?v=dcjkezf1ARY
    • tored 2y ago
      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.
  • redox99 2y ago
    GTK programs look very out of place in Windows.
• markasoftware 2y ago
  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 2y ago
    Anyone can compile a static binary with FLTK and have the binary size start under 100KB.
    • criddell 2y ago
      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 2y ago
        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 2y ago
          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.
    • triedthat 2y ago
      I've used FLTK for an application. It relies heavily on opaque pointers and convention. The compiler will not help you out if you mess up. https://github.com/gammasoft71/Examples_FLTK/blob/c6f630eaa320bce90d6d9096b0718166f0618e32/src/Controls/Input/Input.cpp#L11-L13 https://github.com/gammasoft71/Examples_FLTK/blob/c6f630eaa3...
• Q6T46nT668w6i3m 2y ago
  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 2y ago
    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 2y ago
      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.
• cjk2 2y ago
  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 2y ago
    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 2y ago
      Totally agree with this. I’ll get shot for this one but I write most of my GUIs in Excel these days.
      • mordechai9000 2y ago
        Do you mean Visual Basic for Applications? How are you creating a GUI in Excel?
        • hnthrowaway0328 2y ago
          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 2y ago
            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.
            • 2y ago
• torginus 2y ago
  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.
• Aurornis 2y ago
  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.
  • chipdart 2y ago
    > 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 2y ago
      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.
      • chipdart 2y ago
        CopperSpice is LGPL, not GPL. It's not a problem.
• grahar64 2y ago
  Not an expert, but could you use something like https://enigmaprotector.com/en/aboutvb.html 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.
• mjevans 2y ago
  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.
  • nasretdinov 2y ago
    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 2y ago
      There was an implementation of OpenStep for Windows named OpenStep Enterprise: https://forum.winworldpc.com/discussion/11422/openstep-for-windows-nt 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 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.
      • 2y ago
• mattgreenrocks 2y ago
  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 2y ago
    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 2y ago
      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.
• magicalhippo 2y ago
  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.
  • nurettin 2y ago
    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.
  • chipdart 2y ago
    > 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.
    • magicalhippo 2y ago
      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 2y ago
      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.
    • rubymamis 2y ago
      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/ https://www.get-plume.com/ and it was a breeze.
  • Androth 2y ago
    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.
• beart 2y ago
  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.
  • jb1991 2y ago
    > 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.
  • bowsamic 2y ago
    > Writing GUI apps is painful everywhere, and has been for years. I think UIKit and SwiftUI (and to a lesser extent Appkit) are great
    • webworker 2y ago
      Oddly AppKit seems to be one of the most stable desktop frameworks I have worked with. They've made breaking changes, sure, but they haven't been rewriting, and rewriting, and rewriting the same stuff for the last decade and a half. The situation on Windows these days feels like... cognitive dissonance. If given a Windows app assignment today, I'd pick WinForms if less complicated, WPF if a larger project.
      • bowsamic 2y ago
        AppKit is very stable yes but it shows its age a little more than UIKit. As you say still better than anything Microsoft can offer
  • Dwedit 2y ago
• jcaguilar 2y ago
  This reminded me of The Cherno’s Walnut library: https://youtu.be/-NJDxf4XwlQ https://youtu.be/-NJDxf4XwlQ
  • armchair_expert 2y ago
    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.
• rovingeye 2y ago
  Win32 + WebView2
  • tored 2y ago
    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.
• pan69 2y ago
  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/ https://www.electronjs.org/
  • chipdart 2y ago
    > 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 2y ago
      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.
      • chipdart 2y ago
        > Unfortunely it is built on top of WinUI 3, with all the warts it entails. I'm not sure that's relevant. The whole point of React Native is that you do not touch the underlying framework. Instead of churning out XAML, you just write React and let the framework bother with how the GUI is implemented under the hood.
• canistel 2y ago
  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...
• ogoffart 2y ago
  I'm working on a GUI toolkit that should match the requirements: Slint - https://slint.dev 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.
  • bnolsen 2y ago
    [flagged]
    • ogoffart 2y ago
      There must be some confusion. This is not a web framework, it is a compiled framework with API for several programming languages (including C++) and no HTML/CSS.
    • Klonoar 2y ago
      [flagged]
      • dang 2y ago
        From https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html: "Please don't comment on whether someone read an article. "Did you even read the article? It mentions that" can be shortened to "The article mentions that."" I realize project != article but the same point applies. Note that if by following that guideline, your comment gets "shortened" to the empty string, the implication would be not to post. More helpful, though, would be to supply some specific information.
        • Klonoar 2y ago
          shrug I acknowledge your comment, and I'm aware of the guidelines. I'm not the only one who questioned their response, so I don't feel particularly off balance here.
• slackr 2y ago
  Tried Decker?
• alkonaut 2y ago
  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 2y ago
    > 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.
    • mike_hearn 2y ago
      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.
    • pjmlp 2y ago
      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.
    • 2y ago
• eaterman99 2y ago
  [flagged]
• pugworthy 2y ago
  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 2y ago
    > 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 2y ago
      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.
• theanonymousone 2y ago
  Writing GUI apps is painful, and being probably the most thankless area in Software engineering doesn't help either.
• anthk 2y ago
  Lazarus and Free Pascal might work here.
  • Androth 2y ago
    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.
• markus_zhang 2y ago
  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 2y ago
    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. :)
    • markus_zhang 2y ago
      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.
    • Jare 2y ago
      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.
      • bonzini 2y ago
        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.
• JodieBenitez 2y ago
  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 2y ago
    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.
• philipwhiuk 2y ago
  There's a reason a lot of stuff is Electron.
• c-smile 2y ago
  As of Sciter and "antialiasing" issues mentioned in the article... Author did not enable high-DPI support in his/her application. As simply as that... Either in Visual Studio : https://sciter.com/wp-content/uploads/2024/06/high-dpi-aware.png https://sciter.com/wp-content/uploads/2024/06/high-dpi-aware... Or by including proper manifest: https://gitlab.com/sciter-engine/sciter-js-sdk/-/blob/main/demos/usciter/win-res/dpi-aware.manifest https://gitlab.com/sciter-engine/sciter-js-sdk/-/blob/main/d... That actually is explained in "Hello C++" tutorial: https://sciter.com/hello-cpp-tutorial/ https://sciter.com/hello-cpp-tutorial/
  • mathverse 2y ago
    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 2y ago
      Sciter's support forum is pretty active : https://sciter.com/forums/ 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 2y ago
        Ultimately as a user / customer I dont care who maintains the bindings I need to use to achieve my goal.
        • c-smile 2y ago
          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 https://github.com/AdguardTeam/go-sciter
• deleted 2y ago
  [deleted]
• skrrtww 2y ago
  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.
• ceeam 2y ago
  Who's going to tell him about C++ Builder (Embarcadero)?
  • RachelF 2y ago
    No one wants to talk about it or Delphi anymore. Programmers are just as fashion-concious as the Milan catwalk designers.
    • boznz 2y ago
      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.
      • ak39 2y ago
        Same
  • wiseowise 2y ago
    Wouldn’t that be excluded due to cost?
• gavinhoward 2y ago
  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-framework/ https://gavinhoward.com/2024/05/a-new-architecture-for-a-gui...
• IshKebab 2y ago
  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.
• userbinator 2y ago
  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.
  • crazygringo 2y ago
    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.
    • userbinator 2y ago
      They'll get dark, light, rainbow, whatever the user has set. This was a feature since at least Windows 3: https://news.ycombinator.com/item?id=25871787 https://news.ycombinator.com/item?id=25871787
      • Rohansi 2y ago
        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.
• neonsunset 2y ago
  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 2y ago
    A second recommendation for Avalonia. It deserves the acclaim.
  • Kuraj 2y ago
    Uno is closer to a full stack rather than front-end in comparison with Avalonia.
• jll29 2y ago
  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).
• dmitrygr 2y ago
  “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 2y ago
    Styling functionality doesn't have to imply introducing a new look and feel, it might just be needed for extensibility.
• fleabitdev 2y ago
  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 2y ago
    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 2y ago
      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.html https://raphlinus.github.io/ui/druid/2019/11/22/reactive-ui....
• synergy20 2y ago
  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 2y ago
    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.
• symisc_devel 2y ago
  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.
• lowleveldesign 2y ago
  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 https://github.com/dotnet/winforms/issues/4649
  • neonsunset 2y ago
    COM interop now works on NAOT with source generated COM wrappers: https://learn.microsoft.com/en-us/dotnet/standard/native-interop/comwrappers-source-generation https://learn.microsoft.com/en-us/dotnet/standard/native-int... (it's unfortunate the milestone is set to future in the linked issue though, which includes the light-up for the feature above)
• anothername12 2y ago
  Also check out IUP. It’s lovely to work with and uses native controls. https://www.tecgraf.puc-rio.br/iup/ https://www.tecgraf.puc-rio.br/iup/
• Const-me 2y ago
  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/ 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 2y ago
    WPF has been superseded (supposedly) by UWP / WinGUI / MAUI / Blazor?
    • Const-me 2y ago
      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?
• garaetjjte 2y ago
  >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-and-managed-assemblies https://learn.microsoft.com/en-us/cpp/dotnet/mixed-native-an...
• Dwedit 2y ago
  WX Widgets still exists.
• thefz 2y ago
  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.
• fassssst 2y ago
  Just use WinUI 3. Opting into MSIX packaging no longer requires an App Container sandbox. More info here: https://learn.microsoft.com/en-us/windows/msix/desktop/desktop-to-uwp-behind-the-scenes https://learn.microsoft.com/en-us/windows/msix/desktop/deskt... Full disclosure: I work at Microsoft.
  • withinrafael 2y ago
    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 2y ago
      You can opt out of those with manifest metadata. Capabilities aren't enforced if you distribute out of the app store.
      • withinrafael 2y ago
        The OS will enforce them at installation/launch time regardless of distribution method.
        • mike_hearn 2y ago
          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.
    • jenscow 2y ago
      you can turn some of that crap off: https://learn.microsoft.com/en-us/uwp/schemas/appxpackage/uapmanifestschema/element-virtualization-filesystemwritevirtualization https://learn.microsoft.com/en-us/uwp/schemas/appxpackage/ua...
      • withinrafael 2y ago
• asveikau 2y ago
  > 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 2y ago
    > 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 2y ago
      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 2y ago
        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.
• djbusby 2y ago
  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.
• wiseowise 2y ago
  Did someone suggest Flutter yet?
• deleted 2y ago
  [deleted]
• ZoomZoomZoom 2y ago
  > 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.
  • ozim 2y ago
    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.
  • zigzag312 2y ago
    > 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 2y ago
      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.
• banish-m4 2y ago
  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 2y ago
    A. imgui and SDL2 B. imgui and SDL2
    • banish-m4 2y ago
      That's not what I asked...
  • tored 2y ago
    A. PureBasic B. PureBasic
  • qw 2y ago
    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 (
  • bloblaw 2y ago
    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.
  • petabyt 2y ago
    libui libui
• firebot 2y ago
  There's tools to pack dependencies into a single executable, that then extracts those dependencies, as necessary, upon execution.
• the__alchemist 2y ago
  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 2y ago
    Yes it also works on MacOS, and web as well.
• hermitcrab 2y ago
  >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.
• avsteele 2y ago
  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)
• cryptica 2y ago
  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.
• johnea 2y ago
  Qt is the hero
• Lariscus 2y ago
  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.
  • kelnos 2y ago
    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 2y ago
      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 2y ago
        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
        • mavamaarten 2y ago
          Also trivially achievable by making an installer instead of shipping separate files. People are really used to that pattern.
  • madduci 2y ago
    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.
• shrimp_emoji 2y ago
  Writing anything for Windows is painful. Writing it on Windows is even painfuler.
• bonestamp2 2y ago
  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
• bonestamp2 2y ago
  > 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.
  • mshekow 2y ago
    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
  • shortrounddev2 2y ago
    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
• squarefoot 2y ago
  "Writing GUI apps for Windows is painful" Until you discover Delphi/Lazarus.
  • pjmlp 2y ago
    And C++ Builder as well.
    • squarefoot 2y ago
      Yes of course. Extending the Lazarus ecosystem to support more languages would be a killer feature.
  • cookiengineer 2y ago
    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.
• syngrog66 2y ago
  ah, the intersection of 2 anti-patterns: GUIs and MS Windows. lol
• hgs3 2y ago
  > 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.
• smittywerben 2y ago
  Microsoft: Here are cool windows for Windows. Microsoft: Oh, yeah, to use it, you'll need to deploy it with the Microsoft Store.
• airstrike 2y ago
  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 https://github.com/iced-rs/iced
• fuzztester 2y ago
  Did they try JUCE?
• wolpoli 2y ago
  > 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?
  • athanagor2 2y ago
    Yeah I thought of this too. Wrapping this with Tauri should not be too hard, and quite space-efficient
  • wudangmonk 2y ago
    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!.
  • pjmlp 2y ago
    You just redicovered HTML applications from Internet Explorer 5. Greetings from 1999. https://www.developer.com/guides/ie5s-html-applications/ https://www.developer.com/guides/ie5s-html-applications/
• xbar 2y ago
  For someone who demands so much of other people's open source, the author is quite unwilling to open source their solution.
• throwaway2037 2y ago
  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 2y ago
    .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 2y ago
      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.
      • taspeotis 2y ago
        Oops, I googled it and you’re right.
      • neonsunset 2y ago
        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 2y ago
          "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.
• dkersten 2y ago
  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.
• ChicagoDave 2y ago
  Wouldn’t Electron solve this problem? Build a web app and use Google V8 with your c++ code.
• cerrorism 2y ago
  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.
• graynk 2y ago
  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 2y ago
    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.
• dusted 2y ago
  "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.
• deleted 2y ago
  [deleted]
• bambax 2y ago
  LuaRT (https://luart.org/ https://luart.org/) came up here a couple of months ago; would it meet the requirements?
  • JourneyJourney 2y ago
    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.
• boffinAudio 2y ago
  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 2y ago
    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.
    • boffinAudio 2y ago
      Whats wrong with tkinter? You're negative experience can't possibly be the standard by which 15+ years of productive use of it is to be discarded .. perhaps you haven't learned how to make beautiful UI's with it, but some of us have .. You can easily go from Figma -> tkInter code -> app, too.
• daemin 2y ago
  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 2y ago
    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/ https://www.get-plume.com/
• boxed 2y ago
  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.
• okasaki 2y ago
  > 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.
• mmargerum 2y ago
  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
• robertlagrant 2y ago
  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 https://tauri.app
• gchokov 2y ago
  It was a breeze, back in the RAD / Delphi days..
• p0w3n3d 2y ago
  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...
• donatj 2y ago
  > 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.
• renegat0x0 2y ago
  The requirements are strict. For myself I rarely write app. Most often I self-host programs. GUI is managed by a browser.
• openrisk 2y ago
  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 2y ago
    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 2y ago
      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...
• HumblyTossed 2y ago
  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.
• mrcsharp 2y ago
  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/ https://www.avaloniaui.net/
• jerf 2y ago
  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.
• dgellow 2y ago
  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 2y ago
    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.
• warvair 2y ago
  Just use Godot (https://godotengine.org https://godotengine.org).
• speedypete 2y ago
  Pay for a professional tool and get RAD Studio (C++Builder/Delphi combo) from Embarcadero. https://www.embarcadero.com/products/rad-studio https://www.embarcadero.com/products/rad-studio
• jacinabox 2y ago
  Actually a lot of people are saying that Linux is the best platform for developing GUIs.
  • Andrex 2y ago
    Every OS/environment should have a GNOME Builder equivalent.
• account42 2y ago
  > 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 2y ago
    > 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?
    • marcellus23 2y ago
      Dear ImGui's own readme recommends against using it for user-facing UIs. One showstopper is the lack of accessibility support.
• Log_out_ 2y ago
  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..
• FactKnower69 2y ago
  >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
• ramesh31 2y ago
  > 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.
• bigmattystyles 2y ago
  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)
• pshirshov 2y ago
  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 2y ago
    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 2y ago
      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.
  • demondemidi 2y ago
    Electron = nontrivial effort? What is so hard about Electron? The boilerplate is a snap, compared to Qt/Win32 boilerplate. Where do you fall down?
    • pshirshov 2y ago
      You need something else to run your electron app on mobiles. Ok, you take Capacitor, fine. Probably you'll take React (or something else) to manage your state. Great. You still need some UI toolkit. Literally all of them, even the paid ones, are pretty basic and dumb. So, most likely you'll have to make your UIs pretty basic and dumb, or reinvent the world and/or dig through tons of half-baked libraries which deprecate faster than you manage to integrate them. Modern QT (with QML) has very low amount of the boilerplate, all the 7guis examples can be implemented with 20-80 LoCs and will run on all the platforms, although despite all the modernization efforts, C++ still feels dated and it's nearly impossible to be productive with it. The main issues are: lack of pattern-matching with type deconstruction, lack of ADTs/GADTs, lack of closed hierarchies, lack of exhaustiveness checks, lack of closed type hierarchy (no top/bottom), lack of typeclasses, lack of first-class functions (yes, while there is some syntactic sugar, it's just a sugar, e.g. you can't return two different lambdas depending on the template parameter from one template function).
• demondemidi 2y ago
  As someone who spent most of the early 1990's writing Win32 apps, it doesn't seem like much has changed! MFC has always been a pain to use, especially coming from X and Motif.. even Athena widgets were better than MFC. I've used QT in the past decade for MWL (Mac/Win/Lin) and it is a bit clunky compared to the graphical fluidity of Electron. We just need a solid effort to make Electron smaller. Granted, one can build smaller variants, but even 100 MB is far too large.
• pregnenolone 2y ago
  I've had a good experience with JavaFX and I even managed to AOT compile two faily complex applications of mine. My advice would just be to stay away from FXML. Also use jlink to build a stripped down JRE for your application and package it with jpackage.
• ysc3839 2y ago
  Take a look at Win32 + Xaml Island. You will find that most problems in WinUI 3 gone. Because Xaml Island is a "system component", you don't need to install or bundle anything. And unpackaged .exe is supported. There's one problem, if you want to use Xaml Designer in Visual Studio: Because .xaml files are compiled and packaged into a "resources.pri" file. You have to ship this file with your .exe program. This can be solved by hooking system dll, see my project: https://github.com/ysc3839/SingleExeXamlIsland https://github.com/ysc3839/SingleExeXamlIsland
• masfoobar 2y ago
  While I have dabbled in a number of GUI libraries - many of them were a few years ago so covering my views on those would be disingenuous. I remember using Win32 or MFC.. and dabbled in Qt, etc. In recent years, I have used WPF/Avalonia and while they are good - can lead to a lot of bloat following MVVM. In the last year, I remember needing an application that shows a map. I tried to find support for openstreetmap and, while they exist, did not support what I needed to do. I tried Avalonia, and then GTK, etc. To be honest, I really liked GTK.. it just didn't have the tools I needed, sadly. I have leaned to immediate mode UIs these days. I like I can create something with minimal code. Sadly, no openstreetmap support from what I can see. In the end, I created a web interface. openstreetmap (leaflet) did everything I needed.
• wedesoft 2y ago
  You can just use Qt's DLLs and use NSIS to make a Windows installer. I have developed the Anymeal recipe database software like that and the resulting installer is 20 MByte https://wedesoft.github.io/anymeal/ https://wedesoft.github.io/anymeal/ Also Qt is cross-platform (Windows, GNU/Linux, MacOS).