This is probably the first niche GUI toolkit I've seen on HN that actually does this well. I tried with VO on Mac OS and it just works, no issues to be reported. Most other frameworks of this size have absolutely no accessibility at all. This is why using the platform is a good idea.
Because honestly, you can have the best GUI toolkit in the world but without a visual editor, building a GUI-rich app will still be incredibly tedious.
Probably comes from having more experience with web frontends than native GUIs.
GUI-as-code makes dynamic layout easier, so those GUIs have more hiding and expanding elements. The GUI-as-data approach leans towards a static UI, disabling the elements that don't make sense right now. Dynamic elements exist only via hand-coded widgets, making GUIs more formulaic.
I may be seeing causality where there is none, though.
I've had pleasant experiences with Lazarus, Delphi and Visual Basic, and unpleasant experiences with Qt Designer, Glade and some others.
As Windows users are probably going to be your number one utilizers of target applications, it's always weird that that experience is always the worst. Maybe target WPF/WinUI instead, for a more modern experience.
Standard set of HWND/GDI controls (EDIT,COMBOBOX, BUTTON + so called common controls) is not changing since Win95 so it is a dead end.
And in general modern UI tends to move to composition of UI from primitive ctls achieving rich agglomerates. Like in Web UIs:
<div class="search-input">
<input type="text" />
<button />
</div>
handle WM_DPICHANGED
recreate fonts with actual_dpi/reference_dpi scale factor and send WM_SETFONT
and apply scale factor to all DeferWindowPos() operations.Oh well, maybe someone will write a wrapper for this like relm.
I haven’t tried any yet as I lack the time, but it can be a good starting point.
Iced and Slint where interesting when I looked at that, and Slint may be done by former Qt developers.
25 years ago, during cross-platform toolkits' heyday, it was a different world. People expected more UI consistency because they spent virtually all their time interacting with native applications. The Web did exist, but it was still mostly just a hypermedia viewer plus a few ecommerce sites. XMLHttpRequest was under development at Microsoft but hadn't made it into any publicly available Web browsers. The initial public releases of GMail and Google Maps, arguably the first widely-used modern Web applications, were still 5+ years away.
Fast forward to now, and everyone's completely accustomed to spending most their time interacting with mobile and Web applications that do heavy custom styling and have very little visual consistency with each other, let alone the host operating system. It turns out that we're mostly fine with it. It's not necessarily that there aren't usability problems; it's just that it turns out that inconsistent control styling is nowhere near as much of a problem as poor layout and flow.
So I think that the "it's good for users" argument for native GUI toolkits has largely fallen by the wayside. They still attract me, though. But for a different reason: Electron & friends have poor developer experience. You have to fuss with at least three languages for UI layout, styling, and control, and quite possibly at least one more if doing everything in JavaScript is not your cup of tea. And, frankly, HTML+CSS is a PITA for layout compared to many native GUI toolkits, and wrapping one's head around modern JavaScript frontend frameworks is a much bigger task grokking APIs like GTK+, Cocoa, and WinForms.
I acknowledge that Electron's easy for Web frontend developers, since it introduces very few new concepts, but for the rest of us I think that there might still be value in a cross-platform GUI toolkit that we can all use from our favorite programming language. But I'm starting to think that what it should really look like is something that's fundamentally similar to an Electron-style "we're just going to give you a canvas you can draw in and some tools for drawing in it" approach, only without all the additional technical cruft and complexity that comes with needing to support - and work through - modern Web standards.
In some ways I like what Flutter's trying to do. But it's tied to a specific programming language that I don't already know and don't feel like learning. And it's treating accessibility as an afterthought on at least some platforms, where I think that nowadays it's a non-negotiable that needs to be baked in from the very beginning.
One huge thing that web gets right is that users of the incremental app do not have to install anything. But the consent banners and enshittification of the web experience really eats away at that advantage.
I also very much agree that native look and feel is not as important as it sounds. I'm wondering if there is some obvious way hidden in plain sight to have end user applications on the desktop without incremental installations. Steam is almost there, getting a new game sometimes doesn't feel like a new installation even when it is.