undefined

points

[-]

I think the sweet spot is WPF or actaully its FOSS version: AvaloniaUI. It is high level enough to be cross-platform and not stupidly verbose, however it is rather light pn resources. However, Win32 still wins in absolute minimalism.

by Scharkenberg12 hours ago|

prev|

[-]

While Win32 tends to deliver the most resource-efficient and responsive apps if the complexity is not high, I have settled on the latest .NET + C# + Windows App SDK / WinUI 3. Making an app look good and fit into the modern Windows look is extremely hard with Win32 C/C++ and writing and maintaining it requires energy that I'd rather spend elsewhere. Besides, modern frameworks are making great strides in speed, efficiency and QoL features. .NET 11 is full of optimizations, for example.

by lloydatkinson11 hours ago|

parent|

[-]

I've tried this and found the WinUI deployment model frustrating and user hostile. There are like 5 open issues on GitHub where people seem deeply confused (I'm one of them) as to if it's possible to build a plain .NET .exe. Some people have tried it and it "works", others try it and get obscure errors, it's a real mess.

by Scharkenberg7 minutes ago|

parent|

[-]

Not everything is flowers and sunshine (got a couple of open issues myself... in .NET MAUI too), but whether one can build a single, compact, self-contained exe does not define the hostility of a framework or platform, IMO. .NET was conceived as an enterprise-friendly development framework and that's where it shines the most. Quick-and-dirty/mean-and-lean/distribute-and-forget development was never its forte. I would appreciate that feature too, but it's largely a non-issue.

by chuckadams13 hours ago|

prev|

[-]

Unless your name is Raymond Chen, you probably want to at least use ATL/MFC, which are frozen but still supported. Me, I'd take Qt any day, or wxWidgets if I wanted to go minimal.

by keithnz13 hours ago|

prev|

[-]

yeah, it's still pretty good for a lot of things. I've found with AI it's now super easy to do native win32 apps really easily. It used to be doing all the plumbing was a PITA. There were wrappers to make it easier, but now you can do it directly. It means you get super performant, tiny binaries, that start instantly. Like windows should be. However, at home I've moved to linux a while back so way less useful to me now, though works fine with WINE. I still use it to make little utilities for work though.

by adzm13 hours ago|

prev|

[-]

Win32 API is great and responsive; ATL/WTL (and MFC) are still very useful abstractions with little cost. The biggest pain point is having to handle a lot of things manually, like DPI awareness (and themed controls). Even things like Emoji and other modern text features are not available through GDI and require DirectWrite iirc. Still, I'm surprised how useful it manages to be regardless how old it is.

by queenkjuul9 hours ago|

parent|

[-]

When you say responsive, you mean like it reacts quickly, or it responds to screen size?

In web we refer to the latter but i feel you mean the former.

I built a toy project in .NET 2005[0] with WinForms and the experience was actually excellent, binding data to controls was dead simple, it felt surprisingly modern. But i can't imagine how I'd make the UI resizable lol

[0]https://github.com/queenkjuul/spotify97

by canucker20167 hours ago|

parent|

[-]

Probably more responsive.

Windows apps always had to be able to respond to dynamically changing screen dimensions since the user could change from one screen resolution to another while an app was still running. Apps would get a WM_DISPLAYCHANGE message in their top-level windows message processing loop. Docs say WM_DISPLAYCHANGE was introduced in Win95.

by NetMageSCW12 hours ago|

prev|

[-]

I would say WinForms in C# is still the best today.

by ack_complete4 hours ago|

prev|

[-]

As someone who does raw Win32 API based UI... no. The Win32 UI system has been neglected for many years and is missing very basic functionality by modern standards, including dark mode support, antialiased rendering, hardware accelerated image stretching, and wide color gamut / HDR support. You're going to be working around a lot of ancient restrictions compared to a more modern UI and rendering layers on top of it.

by the__alchemist14 hours ago|

prev|

[-]

I wouldn't, because I do not think we should put up barriers in our application between OSs (Nor have to maintain separate UI code bases for each OS you think might use it). So I use cross-platform kits. There are compromises, but I don't care about the looks native qualification compared to works anywhere. Yes, the software looks like an EGUI app (etc. Substitute Qt), instead of Looks native, but I appreciate how I'm not setting up barriers between OSs or making extra work.

by NetMageSCW12 hours ago|

parent|

[-]

So instead you are creating a bad UI for all of your users. That’s very Java application (or perhaps Electron these days) of you, but seems like a poor trade-off to me.

by the__alchemist11 hours ago|

parent|

[-]

Could you please clarify why you think cross-platform means bad UI?

by Doohickey-d13 hours ago|

parent|

prev|

[-]

These days, with LLM assisted development, with relatively simple GUIs, I would go towards platform native GUIs per platform. And then all the shared business logic goes in a shared "core", with the GUIs only serving as "dumb" inputs and outputs, with all business logic shared between them.

LLMs are quite good at tedious tasks such as keeping multiple GUIs in different languages in sync with each other.

by Rohansi12 hours ago|

parent|

[-]

You still need to test all of those separate GUIs though so it's still costing more.

You also generally don't want them to actually be in sync because there are actual UX differences between platforms that you need to align with to really be native. If you don't follow that then what's the point?

by floydnoel13 hours ago|

parent|

prev|

[-]

I couldn’t disagree more, when it comes to UIs. They should match the platform they are being used on. Cross-platform always produces a very sub-par experience. But us developers tend to care primarily about what makes development easiest for us.

by the__alchemist13 hours ago|

parent|

[-]

What does this mean in practice for software you write? What OSes to you build it for, and what OS or GUI-specific conventions to you follow which don't apply to others?

edit: Link software you wrote's installation instructions.

by floydnoel7 hours ago|

parent|

[-]

You can just look at my profile and see some of it, or check out my website. I’ll have a new app to show soon, so stay tuned!

by Rohansi12 hours ago|

parent|

prev|

[-]

Not everyone has the resources to build five or six different UIs.

by floydnoel7 hours ago|

parent|

[-]

I think it’s better to do a good job once rather than five or six bad jobs, but we all have different priorities.

by Rohansi6 hours ago|

parent|

[-]

The way you worded this message could mean either a) people should focus on a single platform using native frameworks, or b) people should use a cross-platform framework instead of spreading themselves too thin. Maybe even both?

by jen2014 hours ago|

parent|

prev|

[-]

I also don't care how if things _look_ native, I care if the work like a native app. For example, on the rare occasions I touch Windows, I expect standard keyboard shortcuts to work. On macOS, I expect full integration with the accessibility frameworks and OS affordances like services.

A lowest common denominator idea of "everywhere" is just not that useful.

by the__alchemist11 hours ago|

parent|

[-]

How do you handle this for your own software? Could you please link me to one of your project's websites and install instructions? What specifically do you find that one OS has that's mandatory for a good/native UIs that others don't?

I hear you on the native UI is better all things considered. I'm trying to figure out how that works in practice. I.e., to accompany a "cross-platform UIs are inferior to native ones", you would be effective to also include the workflows you use. In a realm where you choose options, eliminating one should come with illuminating another, as one must choose a path, and others could be eliminated for their drawbacks as well, leaving none available. What is your path here?

by jen208 hours ago|

parent|

[-]

No - almost all of the software I work on is at least one of:

- proprietary,

- command line tooling,

- single-platform.

A good example of what I consider to be a great approach (not mine) is Ghostty, which has fully native UI per platform and a shared core between platforms. JetBrains tools also go out of their way to integrate with platform conventions everywhere.

An example that cross-platform toolkits usually get wrong: cursor navigation in text fields. Home and End do different things on different platforms, and on macOS, basic emacs/readline bindings are supposed to work in all text entry fields.

It’s worth noting that this extends beyond GUIs - command line tools written in Go tend to use “package flag” which is native nowhere. The standards between Windows (which has two, in cmd and powershell), GNU-style and “legacy” Unix style are just not reconcilable without implementing platform-specific behaviour.

by jim18014 hours ago|

prev|

[-]

I am having a blast with AI + C + WinAPI. The responsiveness of WinAPI is awesome

by toast014 hours ago|

prev|

[-]

I mean, if I was building a windows app, I would. Microsoft always tries to convince people to stop using it, but Win32 keeps working.

If Microsoft ever makes something that actually meets all the needs that Win32 addresses, they'll probably build a compat layer and a) your win32 code will still work in compat mode, b) that new thing may be worth targeting.