>Alternatively, you can buy a commercial [Qt] license for several thousand dollars.
There is a small business option that is cheaper. But probably still not appropriate for this project.
Writing GUI apps for Windows is painful
201–210 of 577 posts
Re: Writing GUI apps for Windows is painful
#202Earlier 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…
A lot of the best people left MS. People forget that MS was so completely dominant that it attracted a lot of talented people who wanted to do big things. Since then the competition from the FANG companies have brain drained them, not helped by MS insistence on paying less than their peers, sure there is no state income tax but the company shouldn’t be trying to capture all of that difference. The net effect is that…
Also, iirc there is no Windows department anymore at MS. Hard to make a great platform in these conditions.
Re: Writing GUI apps for Windows is painful
#203While 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…
Anyone that has used WinUI since its inception, knows that the best for our sanity is to avoid it at all costs.
It is still years away to provide feature parity with UWP/WinUI 2.0, let alone the Windows Forms, WPF capabilites and Visual Studio tooling.
Using it from C++ is only for ATL / VisuaL C++ 6.0 die hards.
Re: Writing GUI apps for Windows is painful
#204I'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…
Man, as a C# dev, I'd kill for a single exe output. The binary being only 40MB is an absolute fantasy.
We have a project at work, it's nothing crazy, mostly shuffling data from one pipe to another, maybe a few thousand lines of code. A true standalone build including dotnet is over 180MB. The build that relies on the system dotnet install is still over 50MB. It's not even a GUI, it's a background service.
Things on Windows have a bad habit of enormous binary bloat, I'm not sure why. I don't think the problem is near as bad on Linux in general, but I don't have enough experience with linux dev to really say
Re: Writing GUI apps for Windows is painful
#205> It would require me to write a custom paint function for every single control, which would take so much time I could raise a family in the meantime This is a weird comment that shows the philosophy of old school win32 has not clicked for them. The key element in win32 is the wndproc. Most controls ask their parent what color they should be via a window message. If you find this inconvenient, wrapping that in a smal…
> Most controls ask their parent what color they should be via a window message. There are a LARGE number of areas where this is not provided, such as the text color of a disabled control or the checkbox area of a checkbox control. Even for the cases where such customization points were provided, many of them were broken when theming was added in Windows XP and in comctl32.dll version 6 in Vista, which ignores some o…
Do you happen to have links to any good documentation/articles on this topic? I'm working on what amounts to a dark theme for Win32 controls and largely making it up as I go along, relying on tidbits and off-hand mentions from defunct blogs.
Re: Writing GUI apps for Windows is painful
#206More accurately: + "portable" (single exe with no automatic unzipping of dlls or anything) + commercial and unwilling to redistribute compiled object files (which together with the "portable" requirement, means no LGPL) + dark mode Windows GUI apps is painful. Drop any one of these requirements and there are good established options. Specifically I think most "portable" applications use win32 because, usually, portab…
> Windows GUI apps is painful. Drop any one of these requirements and there are good established options. The "portable" one is not a hard requirement. It's a whimsical self-imposed constraint, which makes as much sense as complaining that you can't stand on your right foot on Tuesdays. All installer toolkits released in over two decades support deploying arbitrary components. Is this not a solved problem? WinUI3 sup…
And those COM errors that just kill the process, bypassing C++, and .NET exception mechanisms? lovely!
No designer, manualy editing IDL files for XAML C++ bindings, without any kind of syntax highlighting or code completion, manually merging generated C++ code, even more lovely.
Using a Webview wrapping Bing Maps, instead of the native UWP map control, even better.
Re: Writing GUI apps for Windows is painful
#207More accurately: + "portable" (single exe with no automatic unzipping of dlls or anything) + commercial and unwilling to redistribute compiled object files (which together with the "portable" requirement, means no LGPL) + dark mode Windows GUI apps is painful. Drop any one of these requirements and there are good established options. Specifically I think most "portable" applications use win32 because, usually, portab…
> Windows GUI apps is painful. Drop any one of these requirements and there are good established options. The "portable" one is not a hard requirement. It's a whimsical self-imposed constraint, which makes as much sense as complaining that you can't stand on your right foot on Tuesdays. All installer toolkits released in over two decades support deploying arbitrary components. Is this not a solved problem? WinUI3 sup…
"Portable" i could see a few use cases. No MSIL and only native code, however...
Re: Writing GUI apps for Windows is painful
#208Just use WinUI 3. Opting into MSIX packaging no longer requires an App Container sandbox. More info here: https://learn.microsoft.com/en-us/windows/msix/desktop/deskt... Full disclosure: I work at Microsoft.
WinUI 3 XAML C++ is a joke, versus the old C++/CX tooling in Visual Studio.
Editing IDL files without any kind of Visual Studio tooling, manually merging generated C++ code, no designer.
Re: Writing GUI apps for Windows is painful
#209Earlier quoted context omitted.
Isn't the issue with Qt exactly what the GPL intended? In that case, any Qt fork would force him to also comply with the GPL, and supply the source code of his project.
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 normal static linking, it's only a bit harder. If you ship alongside your binary a bundle of eg .o files and a script that links them together with a .a for the LGPL part for example, this is also compliant without revealing the source code to your non-lgpl part.
Re: Writing GUI apps for Windows is painful
#210Earlier quoted context omitted.
[flagged]
You're being an unnecessary dick. Long compile times are annoying and affect productivity. Some people are really sensitive to this type of disruption and it gets very difficult to stay in flow when the only thing you can do is sit and stare at a progress bar. This is particularly offensive to C# developers. Take your elitist attitude and your gigantic C++ monstrosity elsewhere. Tell me you haven't used a modern JIT…
Ah, yes, I must be a C++ advocate who has never used a “modern JIT language.” I’ve actually been using them since before the term “JIT” was in common use, just like I used C++ before it had templates or exceptions.
Incremental compile time on the order of a minute should not a big deal in a project. How would someone who can’t handle that have fared in our industry 30 years ago? Yes, faster compiles are nice, but they aren’t what will ultimately limit you unless you have an untreated medical condition.