QtWidgets checks nearly all the requirements... > 1\. It should use non-native UI widgets.
It doesn't use native UI widgets, they just look like native. > 2\. Written in Nim with an idiomatic API and DSLs. Of course. But! It should > be compiled to a DLL so that my build times don't suffer. ;-) It's not written in Nim but a wrapper <https://github.com/jerous86/nimqt> is good enough because Nim doesn't have enough resources (people + time) to maintain a project this big, even Go which is a lot more popular had a hard time in this area. > 3\. It should offer a low level API too, powerful enough that custom widgets > can be written easily. It allows you to create custom widgets by drawing text, images, squares, circles... > 4\. Multi-threading ready with clear rules what can be done in a background > thread and what not and how to communicate between threads. Using signals to communicate between QThreads is pretty straightforward <https://doc.qt.io/qt-6/qthread.html#details> > 5\. It should support both the traditional "event based" mode and the even > older "immediate mode" UI. And leave the choice to the final application > which mode I need to work in. Signal/slots > 6\. Small footprint. You cannot compete with Electron based apps so don't > even try. Instead make it run everywhere where a browser cannot be afforded. > This can imply that it works well on embedded devices, but also and more > importantly that it can be used in security critical applications. Small when compared to Electron, it uses a low amount of memory and doesn't use the gpu to render, which is good when running on laptops, but the dlls are kinda big 20-30mb.