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

511–520 of 577 posts

Re: Writing GUI apps for Windows is painful

#511

Post by CrimsonCape »

pjmlp wrote: post #363
ivm wrote: post #268

Earlier quoted context omitted.

WinUI 3 is the default for Windows-only applications

Nah, it is so bad, that on BUILD 2024, they have brought back first level status to WPF. No one burned with WinRT history since Windows 8, is ever touching WinUI, unless they are Microsoft employees on WinDev, or companies with sunken costs trying to keep their products around.

Win UI 3 is the worst kind of improvement because there's arbitrary equivalence between WPF concepts and WinUI concepts, not a 1:1 equivalence. WPF as the mature stable model should be gospel; you don't re-write the gospel. Yet Microsoft feels they should re-write this gospel because... it aligns with the vision (???). Both use XAML, but the concept of DataContext is substantially changed, the concept of bindings is substantially changed, etc. Why make every XAML attribute ever-so-slightly different? Are those changes really an improvement? A lexical improvement? A performance improvement? Or just baggage and overhead to learn?

Compare Microsoft to OpenGL. Boromir says "one does not simply change the OpenGL API..." Microsoft does not have nor ever had OpenGL level of API with their UI frameworks. I guess you could say WPF is maturity in age only but doesn't represent conceptual maturity.

With the differences, you basically throw away all the knowledge of WPF to restart in WinUI, and with poor documentation. The documentation is there, i.e. the "what" but the docs should be primarily "the why and how"; how to map WPF concepts to WinUI3, which is arguably the more critical documentation to provide, and currently pitifully poorly documented.

Doubly so because it would help indicate a measure of feature equivalence; does WinUI 3 currently represent feature equivalence to WPF? Has XAML Behaviors been integrated as a member of the API?

Re: Writing GUI apps for Windows is painful

#512

Post by glzone1 »

kmeisthax wrote: post #298
glzone1 wrote: post #153

Earlier quoted context omitted.

The lack of windows support for windows GUI's on windows is mind blowing. I remember absolutely whipping up Visual Basic line of business apps using the form designer in Visual Studio and data bound controls etc. If you wanted more there was MFC (with MTL developed by some insiders I guess at microsoft) The absolute insanity of going to WPF (wasn't data binding via reflection -> these apps got horribly sluggish!) the…

The problem with all of these technologies is that they were invented by different divisions of Microsoft to do different things. That, and Microsoft chasing the Next Big Thing. What we consider to be "Win32 apps" are built with a framework in USER.dll, which is half reimplementation of the classic MacOS Toolbox API and half a pure-C object oriented class system. It's been here since the beginning, and is the lowest…

The mess this made showed up everywhere.

AppX packages got a bad rep as well for a couple of reasons. Lots of new footguns when dealing with them or trying to remove them for imaging / mass deployment scenarios.

The first introduction to AppX was often a metric load of crap on the machine - see below for a sample of the type of AppX stuff that was the first introduction to AppX for some folks which were often low effort marketing type stuff.

Get Skype: Get-AppxPackage -allusers skypeapp | Remove-AppxPackage Get-AppxPackage -allusers zunemusic | Remove-AppxPackage Get-AppxPackage -allusers maps | Remove-AppxPackage Get-AppxPackage -allusers solitairecollection | Remove-AppxPackage Get-AppxPackage -allusers bingfinance | Remove-AppxPackage Get-AppxPackage -allusers zunevideo | Remove-AppxPackage Get-AppxPackage -allusers bingnews | Remove-AppxPackage Get-AppxPackage -allusers people | Remove-AppxPackage Get-AppxPackage -allusers windowsphone | Remove-AppxPackage Get-AppxPackage -allusers bingsports | Remove-AppxPackage Get-AppxPackage -allusers messaging | Remove-AppxPackage Get-AppxPackage -allusers connect | Remove-AppxPackage Get-AppxPackage -allusers contactsupport | Remove-AppxPackage Get-AppxPackage -allusers feedbackhub | Remove-AppxPackage etc...

Re: Writing GUI apps for Windows is painful

#513

Post by hermitdev »

jnhzubh wrote: post #472
daemin wrote: post #392

Earlier quoted context omitted.

It's especially hard when the application you're building isn't yet proven. As there's no guarantee that it will get any sales, let alone enough to cover the Commercial Qt expenses.

You do not have to pay before your first sale. And $500 is laughable small compared to developer salary. If it saves you half a day of work, you are covered

There is a huge gulf between saving a half a day of work versus _having_ $500 to spend on a tool that would save you that half day of work.

Re: Writing GUI apps for Windows is painful

#514

Post by demondemidi »

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.

Re: Writing GUI apps for Windows is painful

#515

Post by demondemidi »

pshirshov wrote: post #500

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

Electron = nontrivial effort? What is so hard about Electron? The boilerplate is a snap, compared to Qt/Win32 boilerplate. Where do you fall down?

Re: Writing GUI apps for Windows is painful

#516

Post by naitgacem »

throw__away7391 wrote: post #488
pc86 wrote: post #428

Earlier quoted context omitted.

> he didn't want to pay for a license Well that's the killer right there. I too think it's way too painful to write Windows UI, especially if you want to stay away from Electron (which you should in almost all cases), but refusing to pay money for good software is going to severely hamper your goals in 99% of cases.

> stay away from Electron Is this really still true though? VS Code and Slack are all quite polished and give me no issues as a user. Not sure what else I'd consider to build something similar.

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

Re: Writing GUI apps for Windows is painful

#517

Post by flyingpenguin »

MBCook wrote: post #468
wongarsu wrote: post #431

Earlier quoted context omitted.

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.

Right. I want your app to have consistency with the platform I’m using. Not between all platforms. With the exception of games try to use the native GUI. It’s the best choice most of the time.

Depends on the app size also.

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

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

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

Re: Writing GUI apps for Windows is painful

#518

Post by skydhash »

shortrounddev2 wrote: post #452
openrisk wrote: post #450

Earlier quoted context omitted.

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

It seems to have become the no-brainer choice. Lots of mobile apps just load html views, and probably most desktop apps I see these days are just electron apps. You can reason about the best use case for HTML vs XAML vs Swift, but it seems that the speed of development time and the insane amount of community support out there has made the web the clear winner

And the quality of software has gone downhill. HTML and CSS can be RAD, but they rely on millions of line of code in the browser engine while having subpar models for gui layouts and custom widgets. And building a native app is not that necessarily complex, it's just different.

Re: Writing GUI apps for Windows is painful

#519

Post by skydhash »

MaxBarraclough wrote: post #119
serial_dev wrote: post #113

Earlier quoted context omitted.

As a mobile dev, it should be the same for mobile apps? If you are on iOS, you could just use what Apple gives you with very little customizations. The app would feel right, dark mode, font sizes, screen traders, etc. accessibility would "just work" 98% of the time, the app would be fast. On Android, things are a tad bit more complicated, but it still applies that the closer you are to the OS, the better things work…

They also often want to use web technologies and/or cross-platform GUI toolkits, to avoid reimplementing their UIs.

I strongly believe that the amount of ironing they have to do for that crossplatform toolkit takes more time than just going with a common core and different UI shells.

Re: Writing GUI apps for Windows is painful

#520

Post by WorldMaker »

somenameforme wrote: post #499
WorldMaker wrote: post #481

Earlier quoted context omitted.

> And WinUI3 has also already been completely abandoned. I'm not sure where you got that impression, but WinUI3 is in almost all of Microsoft's software at this point. Admittedly a huge amount of it is embedded inside React Native, but WinUI3 seems to be the UI toolkit that has won and is still going strong. They announced a bunch of WinUI3 enhancements at BUILD even. (One such announcement is a coming standard contr…

Visual Studio's designer really does not support WinUI 3. Try it! Hot reload also doesn't work worth anything. There's an ongoing issue/discussion on Github here [1] from 2021. There's also loads of fundamental issues like various controls causing replicable crashes with drag and drop, the community calls are disappearing, and more. [1] - https://github.com/microsoft/microsoft-ui-xaml/issues/5917

Sure, it is definitely very buggy, but the point is that it still exists and is useful to some extent. I was refuting the claim that there is *no* visual editor, not the claim that the visual editor we do have is maybe deficient and buggy.

Relatedly, I still think it is something of a shame that (Expression) Blend didn't survive to the modern era. A designer-focused XAML design tool that doesn't need a full Visual Studio install (nor the same sort of expensive VS license) and feels more like Firefly or Figma or whatever other designer-focused tool is current en vogue would be really handy in a lot of situations.

I don't think it is the only reason that designers tend to prefer HTML (and thus we use Electron or similar to placate the designers that think that "just copy and paste it from the design tool" works "well") over XAML, but it certainly doesn't help that there isn't a "XAML Figma" and it's a shame on multiple levels that Microsoft recognized that threat early on, built a solution, then got confused why they built it, confusingly merged it into Visual Studio licenses and installs, which lead to its sadly inevitable death just a few years before it would have been very helpful to have to send to some designers and stop getting HTML-only mockups.

Post reply on HN