Live data from Hacker News

Writing GUI apps for Windows is painful

tulach.cc

491–500 of 577 posts

Re: Writing GUI apps for Windows is painful

#491

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…

40MB seems like a weird requirement. If it’s under 1GB, I don’t think most people really care any more about executable size. Memory usage is still relevant, but 1GB is going to be less than 1% of disk usage for almost everyone.

Re: Writing GUI apps for Windows is painful

#492
post #373

Earlier quoted context omitted.

I think his complaint is not that he has to pay money per se, but having to pay several thousand dollars. That's a bit much for an independent developer.

I have little sympathy for that kind of argument, imagine a carpenter complaining that they have to buy wood and nails. Besides, a Qt license for small businesses is nowhere near thousands of dollars. Only in software development do we expect quality tools to be given to us free of charge with no strings attached.

wood makes sense to pay for. wood doesn't grow on trees. software works a bit differently though it should also be paid for

Re: Writing GUI apps for Windows is painful

#493

Earlier quoted context omitted.

LGPL. Which eliminates his requirement for a single executable. With LGPL you are only allowed to link dynamically.

Not true at all. The LGPL does not specify anything about mode of linking or anything like that. What the LGPL requires is that the end user be able to take the source code for the LGPL part, modify it, recompile it, and then replace the functionality in your binary provided by that part with their new part. Obviously with dynamic linking this is almist trivial, the end user replaces the so or DLL and done. With norm…

> If you ship alongside your binary a bundle of eg .o files

You might even be able to use partial linking (ld -r) to ship a single .o file instead of a bunch of them.

Re: Writing GUI apps for Windows is painful

#494

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…

40MB seems like a weird requirement. If it’s under 1GB, I don’t think most people really care any more about executable size. Memory usage is still relevant, but 1GB is going to be less than 1% of disk usage for almost everyone.

1GB for each app accumulates really quickly. 40MB is really low, but I wouldn’t be happy with 1GB per app personally. Anything below 500-600MB is fine.

I want my disk space for large medias, not for a desktop app

Re: Writing GUI apps for Windows is painful

#495
post #409

Earlier quoted context omitted.

Winamp comes to mind as a counter example.

IMO, every media player since Winamp 2.x has been largely a step _backwards_ in pretty much every metric one could put forth. It was light-weight, using minimal CPU & RAM. It was skinable. It was reliable. It had great plugin support. I don't recall it leaking memory, either. I basically had it set to auto run on login on my PC. I never closed it. Didn't need to. I had _only_ 32MB of RAM on that computer.

+1.

I still use Winamp, and essentially in its 2.x mode.

Re: Writing GUI apps for Windows is painful

#496

Earlier quoted context omitted.

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.

2400 EUR? Cripes, that is expensive. Do you mind to share the model?

Sure thing: https://www.amazon.de/-/en/gp/product/B07YZ5XT92/ Maybe it was a bit less, 2200 with shipping. I do have a top floor apartment looking south, so I get a constant 30C+ in summer, without any cooling at night.

Re: Writing GUI apps for Windows is painful

#497

Earlier quoted context omitted.

Due to what reasons does imgui offer incredible development speed?

Because adding a text is just a imgui::text("abc") function call. And a button is just an if(imgui::button("click me")) do_something() statement. There is no other language involved, no markup, no gui editor. Just direct code and highly hackable to make this extend to unexpected lengths.

Thanks, got it.

Re: Writing GUI apps for Windows is painful

#498

Earlier quoted context omitted.

1. These wrappers are Open Source. 2. I do not have customers that requested either one of these wrappers. 3. Customers that do use one of wrappers, as AdGuard for example, maintain their own version of Sciter/Go: https://github.com/AdguardTeam/go-sciter

What kind of license do I need to buy for the bindings to be updated?

As with any other Open Source project - contact its author and discuss with him/her.

Re: Writing GUI apps for Windows is painful

#499

Earlier quoted context omitted.

No idea about Apple, but I'd strongly disagree for Microsoft. In one way of speaking, they invest too much. WinUI3, like the article mentions has such a sordid history. It started as WPF, and WPF was (is) awesome. It's simple, clean, runs on a bunch of different platforms, doesn't have a zillion dependencies, has a great community, and is just all around pleasant to work with. So naturally Microsoft decided to comple…

> 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

Re: Writing GUI apps for Windows is painful

#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, there is Avalonia, which is full of bugs. Linux support is remarkably bad.

Also there is Kotlin/Compose Multiplatform. It lacks good documentation, advanced controls and still full of bugs.

I was unable to find any good controls library for JS/TS, even paid ones (like Telerik and others) are pretty messy. So, Electron, Capacitor, React Native - they all assume a non-trivial effort to be put into even a very basic app.

Flutter feels extremely immature, and the strange popularity of global singletons makes it extremely hard to navigate even small codebases.

Post reply on HN