331–340 of 577 posts
Earlier quoted context omitted.
Ultimately as a user / customer I dont care who maintains the bindings I need to use to achieve my goal.
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
Earlier quoted context omitted.
My experience with SwiftUI on the Mac is that it still needs a lot of work. Documentation is poor. Performance can be bad if you do things in a straightforward way. Supporting older versions of the OS is quite painful etc.
> Documentation is poor. This is the first I heard about SwiftUI. Maybe I am mixed up and docs are excellent for Swift, but not SwiftUI?
The documentation was absolutely maddening.. Half the time the Apple docs referred to a previous version. “Do this thing in XCode” often included screenshots of UIs that don’t exist in the current version of XCode. Examples I found on Stackoverflow or random blogs were usually no longer applicable.
It felt like magic when it worked, all those VStack HStack nestings, but the annoyance of finding my way there made me seriously doubt whether I’d build a big app with SwifUI, especially if I wasn’t working alone.
Earlier quoted context omitted.
> Documentation is poor. This is the first I heard about SwiftUI. Maybe I am mixed up and docs are excellent for Swift, but not SwiftUI?
Yes. Two different things. The SwiftUI docs are mostly just listings of functions and not much explanation of how to use them.
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…
Agree. "Single executable" combined with "less than 40mb" is just looking for trouble for what the author is trying to do. If you want to do win32, go ahead and give up styling. Otherwise, make compromises. I think many of these are excellent choices chosen by many programs that I use, it's the author's stringent requirements and unrealistic expectations that is holding back.
In 1999, I built a completely custom Win32 GUI for a (brandable) chat application - that was the product the company I worked for was selling.
Pure C and C++. It was a 32-bit app, not 64 bits. And we felt bad for it being 250KB single executable (skin included in resource section) and not “150KB or less” as was our initial target. But making it accessible and fully skinnable/themable/l10n/i18n did add quite a bit which we hadn’t realized when thinking 150KB was realistic. But it’s not like we resorted to any crazy tricks; that was just the stripped linker output.
It was still a reasonable download at the dominant dial up internet at the time (28.8Kbps IIRC)
Sure, modern tools add a lot of cruft that you’d have to work hard to reduce, but 40MB. Oh man.
tkinter may not be the sexiest way to do things, but its definitely productive in terms of the code-compile-distribute methodology, and it is very easy to wire up to a generalized 'daemon'-style abstraction, where the app logic is implemented as a daemon, sent application commands over a well-greased socket.
With this architecture, I no longer care that its Windows underneath - this is just another platform target - and can easily use either MacOS or Linux as the development environment, needing only to test on Windows, ultimately.
Anything beyond the sphere offered by tkinter is just less appealing. If I have to start treating a platform target in any kind of 'special' way, I just lose interest in that target, as a whole - however, from a UI perspective, Windows tkinter support hasn't been that bad, and generally keeps up fine.
(Disclaimer: if I really need performance, I also use the JUCE framework for my needs - even though its an audio-centric framework, you can build GUI apps with it just as well, and its also a cross-platform way to do things in pure C++ ..)
Reading many of these comments makes me realise that the whole premise is flawed. I "vote" to rename this blog post as: > Writing GUI apps for Windows is painful when requirements are unrealistic They should try to target .NET Framework 3.5 using WinForms. That is my best suggestion, as all recent versions of Windows will have this installed (at least).
.NET since 6 (I think) can be published as a self contained app with the runtime included. It immediately adds some size to the output but you can mitigate it with AOT and trimming.
How about gtk?
I love GTK, but compiling it on non-native platforms is torture. If you're lucky enough to get a build environment working, compilation can take hours just to yield a horribly buggy and slow GUI. I really wish GTK worked better cross-platform, but I mostly use it for Linux-only stuff. It's not humane to make Windows and Mac users suffer through it, unfortunately.
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. ...
ImHex uses it for the entire UI
[0] https://github.com/tildearrow/furnace
Earlier quoted context omitted.
> proper keyboard support Specifically, what does this mean?
I currently see two international keyboard issues: - French Keyboard and Backend SDL2 - Several keys are not checkable with IsKeyDown - Wrong ImGuiKey keydown indexes reported from Win32 backend for some keys when using UK keyboard with UK keyboard layout There are also 2 issues with IME: - Marked Text / SDL_TEXTEDITING Event / IME Composition support - Backspace handling by text widget in default Windows IME environ…
Earlier quoted context omitted.
> Documentation is poor. This is the first I heard about SwiftUI. Maybe I am mixed up and docs are excellent for Swift, but not SwiftUI?
I recently built a small app using SwiftUI. It was my first, and pretty simple. The documentation was absolutely maddening. . Half the time the Apple docs referred to a previous version. “Do this thing in XCode” often included screenshots of UIs that don’t exist in the current version of XCode. Examples I found on Stackoverflow or random blogs were usually no longer applicable. It felt like magic when it worked, all…
> It felt like magic when it worked, all those VStack HStack nestings
EDIT
> made me seriously doubt whether I’d build a big app with SwiftUI