Live data from Hacker News

Writing GUI apps for Windows is painful

tulach.cc

351–360 of 577 posts

Re: Writing GUI apps for Windows is painful

#351

Earlier quoted context omitted.

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

Most games don't use ImGUI, though. Like the parent commenter said, it's useful for debugging, but the actual in-game UI—HUD, inventory, map, etc—is usually rendered by yet another middleware framework like Scaleform, or something that the engine provides (Unreal or Unity).

Nuklear is sometimes used. Anyhow, I do know of some game engines created and used by a (very large) game studio that uses ImGUI. I won't say anything else though :)

Re: Writing GUI apps for Windows is painful

#352
post #327

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

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.

Re: Writing GUI apps for Windows is painful

#353

I'm working on a GUI toolkit that should match the requirements: Slint - https://slint.dev Can be compiled statically in a single .exe that is smaller than 40M. Has a license that allow proprietary on desktop for free. Has dark/light styles. Even comes with a (work in progress) drag and drop WYSISYG editor.

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

Re: Writing GUI apps for Windows is painful

#354

Earlier quoted context omitted.

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

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

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.

Re: Writing GUI apps for Windows is painful

#355
post #332

Earlier quoted context omitted.

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…

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 bi…

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.

Re: Writing GUI apps for Windows is painful

#356

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, portab…

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

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

Re: Writing GUI apps for Windows is painful

#357

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

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

Re: Writing GUI apps for Windows is painful

#358

Earlier quoted context omitted.

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)

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.

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

Re: Writing GUI apps for Windows is painful

#359
post #102

Earlier quoted context omitted.

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.

>I still use Windows Forms in .NET 4.8 and my executables are Do you need to ship any supporting files separately, along with the app? And is .NET 4.8 or higher already on Windows PCs?

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.

Re: Writing GUI apps for Windows is painful

#360

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

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

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

Post reply on HN