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

221–230 of 577 posts

Re: Writing GUI apps for Windows is painful

#221

Post by leapingdog »

userbinator wrote: post #85

Problem: It is extremely hard to stylize native Win32 controls. That's not a problem, it's a feature. I am absolutely bloody sick of apps that go out of their way to reinvent the standard UI controls in perplexing ways and behave unexpectedly. Following the system UI preferences is what you should do, and it irritates your users if you don't. There is a “hidden” dark mode for Win32 controls used by Windows File Explo…

I agree with you.

> Easy styling, including dark mode

I wonder if this requirement has been imposed from above.

When the web was taking off I received designs from the UI architect in the form of VB6 applications. Windows was the dominant platform at the time. Never mind it made no sense in the context of more fluid HTML layouts. This was before CSS.

Since then the web has probably trained the holders of the reins that they can violate user interface norms everywhere.

Re: Writing GUI apps for Windows is painful

#222

Post by Paradigma11 »

bpfrh wrote: post #31
mdorazio wrote: post #17

Earlier quoted context omitted.

Are portable AC units not available in Europe? They are inefficient but can sit inside next to the window and only require that you partially block off a window opening.

They are but not as efficient and so most people don't bother(that I know of).

I bought a portable split system for 2400 EUR. Works pretty well since I have shutters and a balcony, I put the external part outside the window, pull down the shutters and seal the lower part of the window around the pipe with some stuff. Doesn't use lots of power if I cool to 26C. Well, today we had 34C outside, so it had to work a lot.

Re: Writing GUI apps for Windows is painful

#223

Post by smileybarry »

chipdart wrote: post #48
alkonaut wrote: post #40

While it’s a bit cumbersome, he doesn’t really point out any major flaw with the WinForms/WPF ideas, other than of course requiring two stacks. He says he wants native code and wouldn’t want any C# visible but doesn’t explain why. Fear of reverse engineering? UI code rarely contains anything secret. Also the single exe deployment, while convenient at times, is perhaps not worth the hassle in this scenario. Using a pa…

> While it’s a bit cumbersome, he doesn’t really point out any major flaw with the WinForms/WPF ideas, other than of course requiring two stacks. He says he wants native code and wouldn’t want any C# visible but doesn’t explain why. Fear of reverse engineering? UI code rarely contains anything secret. What I find the most mind-numbing thing about the blog post is the way WinUI3 was excluded. WinUI3 looks like an exac…

WinUI3 is a can of worms that’s becoming palatable only with .NET 8 (and soon 9). In a normal configuration, you have to bring 500MB of dependencies with you, or ask the user to install a redistributable. You also need the user to install .NET 8, or bring said 0.5GB with you.

WinUI3 can be used in unpackaged apps (I.e.: not appx) but has a few random caveats that just don’t work; random APIs that have a footnote of “oh this doesn’t work in unpackaged apps” or “works in unpackaged apps but only in .NET Preview something-something”.

.NET 8 fixes a lot of this by adding AOT compilation and single-binary releases, but it’s still fairly large. .NET 9 then improves culling of unused framework code from your published file, and also adds WPF -> WinUI3 theming support.

Source: my repeated attempts to rewrite our product’s UI in WinUI3 (from WPF on .NET Framework 3.5) several times.

Re: Writing GUI apps for Windows is painful

#224

Post by smileybarry »

vunderba wrote: post #79
alkonaut wrote: post #40

While it’s a bit cumbersome, he doesn’t really point out any major flaw with the WinForms/WPF ideas, other than of course requiring two stacks. He says he wants native code and wouldn’t want any C# visible but doesn’t explain why. Fear of reverse engineering? UI code rarely contains anything secret. Also the single exe deployment, while convenient at times, is perhaps not worth the hassle in this scenario. Using a pa…

Agreed. I had the exact same question. From the article: "The issue is that with bundling the .dll, it would still mean it being extracted somewhere and writing additional code for the P/Invoke to work, and C++/CLI gets compiled to .NET IL code, in other words, you can open the resulting app in dnSpy and see the C++ code translated to C# equivalent (which is not what I want, I want native code)." I don't understand w…

C++/CLI is managed code, it’s basically C++ compiled into .NET IL.

If you’re writing C++ code running on .NET / .NET Framework, you’re basically writing masochistic C#.

Re: Writing GUI apps for Windows is painful

#225

Post by leapingdog »

CyberDildonics wrote: post #193
ogoffart wrote: post #38

I'm working on a GUI toolkit that should match the requirements: Slint - https://slint.dev Can be compiled statically in a single .exe that is smaller than 40M. Has a license that allow proprietary on desktop for free. Has dark/light styles. Even comes with a (work in progress) drag and drop WYSISYG editor.

Where did the idea come from that starting with a 40MB exe is small? That's completely outrageous. You could embed all of python, tk, fltk, wxwidgets and pyqt and still not be close to 40MB. FLTK static binaries start at 100KB, win32 binaries can start at 1KB, Juce is about 2MB. Using GLFW or SDL for an openGL window then using IMGUI would start at a few hundred kilobytes. What are you doing in there that makes your…

I don't know for certain but expect it comes from comparing solutions with those based on virtual machines like Java's. The requirements in the original article look like a corporate wish list.

Re: Writing GUI apps for Windows is painful

#226

Post by ozim »

ZoomZoomZoom wrote: post #186

> uses native Win32 components and offers no styling options It's a feature. Custom styling should be considered a hostile pattern in most cases, except in highly specialized software with workflows dependent on prior user experience, such as DAWs.

Yes full agreement from me.

I think loads of energy is wasted in development because someone wants custom stuff like buttons or input boxes without real reason where off the shelf GUI would work and would be much cheaper.

Re: Writing GUI apps for Windows is painful

#227

Post by EasyMark »

Aurornis wrote: post #19

This is a good overview of some of the options, but the author’s specific requirements push it in a specific direction that eliminates a lot of options. Specifically, the requirement for completely custom GUI styling without writing his own render functions means it’s really a task of selecting easy, customizable GUI libraries rather than generic GUI work. The requirements to be self-contained executables and under a…

If you’re on windows and want a “standard” guy, either use the .net GUI or Qt , if you want completely custom and willing to do the work use QML or ImGui (or variant like eGUI)

Re: Writing GUI apps for Windows is painful

#228

Post by EasyMark »

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.

I never understood the need for a single executable on windows when folders, zip files, and 100% free installers exist if you don’t like zip files. Also nearly all of the gui kits he’s shooting down have ways to build custom components if that’s what you want to do.

Re: Writing GUI apps for Windows is painful

#230

Post by Lariscus »

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