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…
Writing GUI apps for Windows is painful
491–500 of 577 posts
Re: Writing GUI apps for Windows is painful
#492Earlier 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.
Re: Writing GUI apps for Windows is painful
#493Earlier 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…
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
#494This 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.
I want my disk space for large medias, not for a desktop app
Re: Writing GUI apps for Windows is painful
#495Earlier 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.
I still use Winamp, and essentially in its 2.x mode.
Re: Writing GUI apps for Windows is painful
#496Earlier 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?
Re: Writing GUI apps for Windows is painful
#497Earlier 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.
Re: Writing GUI apps for Windows is painful
#498Earlier 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?
Re: Writing GUI apps for Windows is painful
#499Earlier 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…
[1] - https://github.com/microsoft/microsoft-ui-xaml/issues/5917
Re: Writing GUI apps for Windows is painful
#500Apart 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.