Live data from Hacker News

Writing GUI apps for Windows is painful

tulach.cc

561–570 of 577 posts

Re: Writing GUI apps for Windows is painful

#561
post #170

Earlier quoted context omitted.

> The painful bit is C++. I did a fair bit of that going back to MFC. I'm sorry but referring to MFC while referring C++ is a telltale sign you don't really have any meaningful experience in the field. Developing GUI apps for Windows is a breeze with frameworks like Qt. You only suffer if you're a masochist, but the rest of us prefer to pick things that make sense.

I have a lot of experience, in the real world, which is somewhat less ideal than "just use Qt - it's a breeze". How do you manage a 15 million LOC desktop app originating from the late 90s which contains chunks of win32 native, ATL, MFC, custom GDI+ wrappers all sorts? Aye you fuck off and work somewhere else that's what you do. Which is why it's still written in win32 native, ATL, MFC, custom GDI+ wrappers. They pai…

> How do you manage a 15 million LOC desktop app originating from the late 90s which contains chunks of win32 native, ATL, MFC, custom GDI+ wrappers all sorts?

You're complaining about your personal legacy "chunks of win32 native, ATL, MFC, custom GDI+ wrappers".

Not C++. Just your personal legacy projects you didn't managed to maintain or update.

C++ doesn't magically rewrite your technical debt. You need to do your work.

Re: Writing GUI apps for Windows is painful

#562
post #379

Earlier quoted context omitted.

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

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.

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

Re: Writing GUI apps for Windows is painful

#563

Earlier quoted context omitted.

I have been trying to learn WPF for a long time, but have drifted into web apps. Can you point me to any good resources to be able to make complex multi window apps in it? I have good experience in Windoes forms and am well versed in c# and dotnet.

I’ve learned WPF long ago, and I no longer remember how specifically I did that. Still, that introduction seems pretty good at the first sight: https://wpf-tutorial.com/ Learning is easy, it’s very user friendly and IDE support is great. Mastering the framework for complicated GUI is harder. Here’s a few tips. Treat XAML the same way as any other source code. Keep it human readable: write comments (the syntax is the…

Thank you for your patient and detailed response.

Re: Writing GUI apps for Windows is painful

#564

Earlier quoted context omitted.

Yes, closed source libraries are a pain to work with. This is why I like the GPL/Commercial dual licensing model. You can try it out for as long as you like, have full access to the source code and can even create commercial software for free. You are only required to pay for a license if you want to create closed source software. I consider this an absolutely fair deal, yet the blog author seems to take issue with t…

That’s fair in theory, but it really feels that they’ve made it more difficult to find the open source version of Qt last I checked. I haven’t tried to use it in a while, but I recall last time I tried I just gave up.

Unfortunately they do and they really try to scare you away with the GPL boogeyman. It is a fair criticism. I would recommend to ignore the installer entirely and rely on a package manger like vcpkg, conan, apt, or brew instead.

You can find the manual installer here:

https://www.qt.io/download-qt-installer-oss

Re: Writing GUI apps for Windows is painful

#565

Earlier quoted context omitted.

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.

Netflix took this to an extreme, apparently porting WebKit to the PS3 just to power their app's UI.

With apologies for linking to such an appallingly spammy website, as I couldn't find a better one:

https://www.engadget.com/2010-12-07-netflix-ported-webkit-to...

Re: Writing GUI apps for Windows is painful

#566
post #124

Earlier quoted context omitted.

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.

I don't know much about the performance, but I guess non-action games should be fine?

The GameSDK samples included scrolling backgrounds and that kind of stuff.

Re: Writing GUI apps for Windows is painful

#567
post #558

Earlier quoted context omitted.

I mean, if you're willing to do that why not just dynamically link?

The OP article is saying that static linking leads to size reduction. That's why asking.

You’re not getting a size reduction if you maintain a library boundary, though. What you’re doing is isomorphic to dynamically linking except the app code is in the library and the library code is in the main binary.

Re: Writing GUI apps for Windows is painful

#568
post #372

Earlier quoted context omitted.

I don’t have much app experience, I’m mostly a back-end guy trying to build some prototypes and (hopefully) one product. I’m not in a position to give anyone advice, but I’d love to find SwiftUI but cross-platform and usable from anything other than XCode (well maybe not Ed…) and native GUI and a pony. For my product I need to support Mac, Windows and eventually iOS/iPadOS. For prototypes iOS is enough. I don’t mind…

If you really want native look and feel then really your only choice is to use the native toolkits. I'm not convinced many users care that much about this though. They spend most of their day using apps that don't use native controls and I think they're all pretty used to it by now. I prototyped a bunch of different desktop toolkits and I think that today Flutter is by far the most polished and mature. I've had overa…

    > If you really want native look and feel then really your only choice is to use the native toolkits.
What about Qt?

Re: Writing GUI apps for Windows is painful

#569
post #558

Earlier quoted context omitted.

The OP article is saying that static linking leads to size reduction. That's why asking.

You’re not getting a size reduction if you maintain a library boundary, though. What you’re doing is isomorphic to dynamically linking except the app code is in the library and the library code is in the main binary.

Ok. I understood. Thanks for explaining.

Re: Writing GUI apps for Windows is painful

#570
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

Post reply on HN