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

551–560 of 577 posts

Re: Writing GUI apps for Windows is painful

#551

Post by somenameforme »

WorldMaker wrote: post #520
somenameforme wrote: post #499

Earlier quoted context omitted.

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

To be clear I am saying that drag and drop operations do not work during runtime. The designer literally does not work at all, for WinUI 3, for reasons that are not at all clear, since Visual Studio had a 'native' designer for WinUI 2, as well as the weird disconnect with Blend as you mentioned.

I almost feel like you're mixing up WinUI 2 and 3, because the designer was kind of borky for WinUI 2 but did work, and was overall an okayish experience. But for WinUI 3 it's an entirely different game. Early on the messaging was that the designer would be "coming soon" (tm) and that people could just use hot reload in the interim, then at some point hot reload ended up completely broken as well, Microsoft gradually started withdrawing engagement with the community, and here I am saying it's been defacto abandoned.

The point of the designer is not just mock ups. At many (most?) small businesses and studios the developer/designer dichotomy doesn't exist. There's a reason lots of companies are still even using e.g. Winforms. A high functioning designer simply dramatically improves both productivity and quality.

Re: Writing GUI apps for Windows is painful

#552

Post by alkonaut »

brnt wrote: post #510
alkonaut wrote: post #360

Earlier quoted context omitted.

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.

Why 4.6 and not 4.8? (I assume you mean .Net Framework and not .Net.)

4.6 instead of 4.8 because 4.6 comes preinstalled with any Windows (Any supported Windows that is, i.e. Win10/11 or equivalent server), so from the user's perspective it will be a no-dependency app, just like a Win32 app.

Re: Writing GUI apps for Windows is painful

#553

Post by alkonaut »

scruple wrote: post #527
brnt wrote: post #510

Earlier quoted context omitted.

Why 4.6 and not 4.8? (I assume you mean .Net Framework and not .Net.)

Anyone reading this thread will surely roll their eyes and move on to a different solution. Event the people who recommend this stuff to others get confused about what the fuck is even happening in the .NET ecosystem.

It was pretty simple up until the whole netcore fork and netstandard confusion. Then it was confusing for a number of years. And now it's actually pretty simple again.

The naming of ".NET" and ".NET Framework" is confusing as hell. But basically Microsoft is hellbent on launching something completely new and having that take over the .NET name, even if it means years of confusion.

Re: Writing GUI apps for Windows is painful

#554

Post by Const-me »

stinos wrote: post #547
Const-me wrote: post #125

For requirements like that, I typically write WPF C# frontend, combined with C++ backend. Compared to ImGui, in WPF you’ll get a GUI designer, styling which allows easy dark mode, data bindings, data templates, animations, IDE support like live visual tree inspector, accessibility support, and more. If you use the legacy .NET 4 framework, the .NET runtime will come pre-installed on modern Windows. If you compile your…

I do not recommend C++ CLI. Can you elaborate on why? I looked at various ways for interop between C# and C++ over the years, and overall found C++/CLI to be the best overall for our particular application types: it's a separate layer bewteen a C++ backend (which is also used in other non-gui applications), with a windows-only WPF desktop application on top. Mainly because the C++/CLI code itself is simple, readable…

> Can you elaborate on why?

The language is only supported in a single compiler, and is specific to Windows.

The language is based on both C++ and .NET runtimes, and when I used it (admittedly, it was many years ago) I didn’t like the usability consequences. These two runtimes interact in a weird way. It’s hard to compose data structures which contain both managed and unmanaged pieces, see that question https://stackoverflow.com/q/10523268/126995 You can’t include Windows SDK headers in CLI code, not gonna compile: https://stackoverflow.com/q/26502283/126995 Same applies to most third-party C and C++ libraries.

So with CLI you have 3 languages instead of just two: C#, C++/CLI, and classic C++.

> it's exactly the type of code I'd rather not write

I have used that library in multiple projects in the last 5 years, for Windows and Linux platforms including ARM Linux, both open source and commercial. It worked great for my use cases.

Here’s an open-source example of a relatively complicated COM interface implemented on top of ComLightInterop. C# interface: https://github.com/Const-me/Cgml/blob/master/CGML/CgmlNet/iC... C++ interface: https://github.com/Const-me/Cgml/blob/master/CGML/Cgml/API/i... C++ implementation: https://github.com/Const-me/Cgml/blob/master/CGML/Cgml/D3D/C...

As you see it has very few macros, no bool returning methods, very clean API between managed and unmanaged parts, and most importantly very readable idiomatic codes on both sides of the interop.

I’d like to add that if you make mistakes when writing these C++ and C# projection of a COM interface you’ll find very soon because it’s likely to crash on first use due to /GS compiler switch. Also trivial to debug and fix because VS supports mixed-mode debugging.

Re: Writing GUI apps for Windows is painful

#555

Post by whywhywhywhy »

estebank wrote: post #474
HumblyTossed wrote: post #421

Earlier quoted context omitted.

> Like shouldn't Windows 11 just either have that already or pull it down as needed as it's an official MS library. In this day and age of everything always connected, some things still aren't always connected.

The app manifest could state "I need this runtime installed". The OS can know whether it is already installed or not. The OS also knows whether it is internet connected or not. If a runtime that isn't installed is needed and internet connectivity isn't available, the OS could state that, with information about how to procure the runtime manually. That would stop people that have copied thr application from a pendrive…

The OS presumably also knows where I should get it from as the same company hosts the installer as ships the OS. Yet IIRC the error is just an obtuse thing complaining a DLL isn't there and through googling and hopefully finding your way to Microsoft.com not some malware site you have to find the installer yourself.

Mild annoyance for someone with 28 years Windows experience, complete roadblock or malware vector for someone who just wants to use a computer rather than understand a computer.

Re: Writing GUI apps for Windows is painful

#556

Post by Const-me »

kumarvvr wrote: post #425
Const-me wrote: post #125

For requirements like that, I typically write WPF C# frontend, combined with C++ backend. Compared to ImGui, in WPF you’ll get a GUI designer, styling which allows easy dark mode, data bindings, data templates, animations, IDE support like live visual tree inspector, accessibility support, and more. If you use the legacy .NET 4 framework, the .NET runtime will come pre-installed on modern Windows. If you compile your…

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 same as in XML i.e. ), and use proper indentation (I often use tab size = 2 for XAML files). When a particular window or control grows too huge, consider moving large pieces into separate XAML files with a user control or maybe a resource dictionary.

MVVM design pattern is great, use it whenever possible. Don’t forget to implement INotifyPropertyChanged and/or use ObservableCollection for dynamic things. Having said that, I tend to avoid opinionated MVVM frameworks like Caliburn.Micro, IMO these things sacrifice simplicity for testability.

Sometimes for complicated UX use cases like drag/drop or mouse painting handling these input events in code behind is way simpler than trying to stick with MVVM. Luckily these approaches compose rather well; it’s possible to use MVVM for most of the UX and code behind logic only in the few places where it simplifies things.

Similarly, for diagrams or similar GUI you can directly create and manipulate these UI elements with C#, placing then on a canvas. Technically possible to do in MVVM-y way e.g. an ItemControl with a Canvas in the ItemsPanel, just much harder to do especially the layout on resize. BTW, you can define styles for these elements in XAML markup, no need to set up every possible font/brush in C#.

Couple advanced features I often use are IValueConverter interface to translate values or types between views and view models, and DataTemplateSelector to programmatically switch between multiple data templates.

I tend to avoid DataTrigger in XAML, I prefer exposing additional public properties from my view models.

Re: Writing GUI apps for Windows is painful

#557

Post by Lariscus »

zer0zzz wrote: post #502
Lariscus wrote: post #230

I have a very low opinion of developers who decry having to pay for a commercial licence for otherwise LGPL licensed software libraries. They expect to be paid for their work, and ensure that by creating closed source software. That's fair enough. Yet, the devs that solved the actually difficult parts of creating a UI library have to be utter saints who freely bestow a gift of code upon the world.

No, it makes perfect sense to complain about paid software libraries because it inevitably makes getting to them a huge pain in the ass and that causes folks who just want to easily give the library a try every reason to go try something else. Then as a result the ecosystem of apps using sad framework begins to stagnate.

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 that which is what I am criticizing.

Re: Writing GUI apps for Windows is painful

#558

Post by alok-g »

saagarjha wrote: post #542
alok-g wrote: post #410

Earlier quoted context omitted.

Cool! Does this also mean that one could put most of the closed source part into a DLL, make a shell executable that is open source and statically link LGPL code into the latter? This then would allow modifications to the LGPL code to be put in just by having the closed source DLL.

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.

Re: Writing GUI apps for Windows is painful

#559

Post by PKop »

kumarvvr wrote: post #425
Const-me wrote: post #125

For requirements like that, I typically write WPF C# frontend, combined with C++ backend. Compared to ImGui, in WPF you’ll get a GUI designer, styling which allows easy dark mode, data bindings, data templates, animations, IDE support like live visual tree inspector, accessibility support, and more. If you use the legacy .NET 4 framework, the .NET runtime will come pre-installed on modern Windows. If you compile your…

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 liked this Pluralsight WPF course a lot, the instructor (Thomas Claudius Huber) is clear in his explanations and seems to be very knowledgeable.

https://www.pluralsight.com/courses/wpf-6-fundamentals

Re: Writing GUI apps for Windows is painful

#560

Post by zer0zzz »

Lariscus wrote: post #557
zer0zzz wrote: post #502

Earlier quoted context omitted.

No, it makes perfect sense to complain about paid software libraries because it inevitably makes getting to them a huge pain in the ass and that causes folks who just want to easily give the library a try every reason to go try something else. Then as a result the ecosystem of apps using sad framework begins to stagnate.

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