Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Writing GUI apps for Windows is painful

tulach.cc

Post reply on HN
Print view View original

431–440 of 577 posts

Re: Writing GUI apps for Windows is painful

#431

Post by wongarsu »

klabb3 wrote: post #383
barrkel wrote: post #161

Earlier quoted context omitted.

This indeed. Custom UI widgets for Windows apps are really not necessary most of the time, and fitting in with the system theme is all you ought to aim for, most of the time. There are exceptions, for very rich dense UI, for UIs that need to be cross-platform, but if you're writing a Windows app, it should look and feel like a Windows app.

> There are exceptions, for very rich dense UI, for UIs that need to be cross-platform That’s not exceptional at all. That’s completely normal requirements that are probably in the majority. Does Microsoft themselves build their apps this way?

Most applications would be fine with a button on Windows looking like a Windows button, a button on Mac looking like a Mac button, a button on Android looking like a Material Design button and a button on iPhone looking like a UIKit button.

You need consistency in the icons, layouts and concepts, but you don't need every widget to look exactly the same on every platform.

Re: Writing GUI apps for Windows is painful

#432

Post by ToucanLoucan »

klabb3 wrote: post #383
barrkel wrote: post #161

Earlier quoted context omitted.

This indeed. Custom UI widgets for Windows apps are really not necessary most of the time, and fitting in with the system theme is all you ought to aim for, most of the time. There are exceptions, for very rich dense UI, for UIs that need to be cross-platform, but if you're writing a Windows app, it should look and feel like a Windows app.

> There are exceptions, for very rich dense UI, for UIs that need to be cross-platform That’s not exceptional at all. That’s completely normal requirements that are probably in the majority. Does Microsoft themselves build their apps this way?

> Does Microsoft themselves build their apps this way?

I'm not sure anyone could really answer this question considering how fast Microsoft's various silos pinball between UI conventions. All of them are (I would hope) based on various iterations of their own internal tooling, but looking from Windows 7 to 8, 10, and then 11, you get such stark differences in UI language that you feel like you're looking at competing products.

That being said, I would personally very much prefer apps that are built to mimic the system they are a part of. One of the worst sins of that one, IMO, being iTunes on Windows which has always been and continues to be a flaming dumpster fire for a number of reasons, but most especially it's UI. It is a Mac app that is parked in Windows. It looks like a Mac app, it operates like a Mac app, it's UI conventions are that of the Mac, with the one major difference being they stuffed the window controls in the window in an incredibly slapdash way to account for Windows not having the system bar.

But yeah, for any marketing people here, I have not once nor will I ever give a single molecule of a shit about your brand identity. Make your software good. Ideally make it mesh with the system it's in. I couldn't fucking care less what color everything is.

Re: Writing GUI apps for Windows is painful

#433

Post by MarkSweep »

AmateurAlert wrote: post #336
taspeotis wrote: post #299

Earlier quoted context omitted.

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

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.

Windows Forms is also making some progress on being fully AOT compatible:

https://github.com/dotnet/winforms/issues/4649

Re: Writing GUI apps for Windows is painful

#434

Post by TheCoelacanth »

deutschepost wrote: post #152
jjmarr wrote: post #107

Earlier quoted context omitted.

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

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

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

Re: Writing GUI apps for Windows is painful

#435

Post by ToucanLoucan »

pc86 wrote: post #429
therein wrote: post #377

Earlier quoted context omitted.

> and fitting in with the system theme is all you ought to aim for, most of the time Even Microsoft struggles with that.

Only because they change the system theme every 45 minutes.

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

Re: Writing GUI apps for Windows is painful

#436

Post by bobajeff »

cageface wrote: post #272
eschaton wrote: post #88

Earlier quoted context omitted.

If instead of insisting on custom UI styling the author just used the system UI, they could probably build a pretty straightforward Windows application. It’s the scourge of “brand identity” that has people thinking graphical applications are hard. Same on the Mac: If you want to build a Mac application, your best bet will be AppKit or SwiftUI and using system controls. And when the OS updates your application will ei…

My experience with SwiftUI on the Mac is that it still needs a lot of work. Documentation is poor. Performance can be bad if you do things in a straightforward way. Supporting older versions of the OS is quite painful etc.

Documentation remains the number one reason I personally don't make Android apps and why electron/web apps are the way to go for most GUI apps these days.

Re: Writing GUI apps for Windows is painful

#437

Post by pjc50 »

neonsunset wrote: post #369
AmateurAlert wrote: post #336

Earlier quoted context omitted.

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.

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

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

Re: Writing GUI apps for Windows is painful

#438

Post by Liquid_Fire »

alok-g wrote: post #413
chipdart wrote: post #67

Earlier quoted context omitted.

CopperSpice is LGPL, not GPL. It's not a problem.

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

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

Re: Writing GUI apps for Windows is painful

#439

Post by shortrounddev2 »

openrisk wrote: post #420

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

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

Re: Writing GUI apps for Windows is painful

#440

Post by shortrounddev2 »

bonestamp2 wrote: post #259

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

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
Post reply on HN