281–290 of 577 posts
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.
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…
This is super clever, I love it! Does any software actually do this?
Earlier quoted context omitted.
WPF has been superseded (supposedly) by UWP / WinGUI / MAUI / Blazor?
Nope, the GUI story is so bad, that at BUILD 2024, WPF was made again an official Windows GUI framework for .NET devs, see BUILD 2024 sessions regarding Windows programming.
I remember when WinForms (which I thought was fine!) was killed. Why they just didn't continue to build on that I don't know (yes, I've heard the explanations, the importance of things like having XML (barf) in the framework).
How can you not be absolutely kicking butt on your own platform with a great story especially because they absolutely HAD a great story both at entry level LOB and advanced LOB.
Earlier quoted context omitted.
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)
Which particular .NET Gui? There is a collection of them: MAUI, WPF, Blazor Hybrid, WinUI. Microsoft have utterly screwed the pooch on getting their .NET GUI story straight.
Earlier quoted context omitted.
Dear ImGui is for development/debug tools, not an UI for the end-user. It's great for small projects as long as you don't care about accessibility, or proper keyboard support, or adherence to standard UI conventions, or support for devices without GPUs, proper font rendering, etc. ...
It's also suited to games, where "non standard" UI is expected and part of the experience.
Computers come with a modern browser now. Instead of a .exe file, could it be, let's say, a single .html file with inlined image/css/javascript?
> Writing the GUI part of the program should not take more time than the actual functionality I don't understand why this is a rule. I mean, I don't know what the author is trying to build, but in general the GUI is the part that the users spends all of their time interacting with. I don't see why it would be a problem if a little more time was spent there.
Also, in my experience, writing UI code is usually more(!) work than writing the functionality underneath, because
a) styling / layouting has to be learnt from scratch (e.g. because of a proprietary language, e.g. QML or QWidgets for Qt)
b) you have to take care of every frikkin' single user interaction (which becomes worse the more dynamic and custom your UI is), and building proper accessibility is also no walk in the park