81–84 of 84 posts
wxWidgets has a sublime idea: an api that is just a wrapper over native controls. For cross platform frameworks it is fast and light. The very opposite of bloatware. But it also has a terrible flaw: its heavy-templated C++ api, hard to port to other languages. I don't want to get stuck on C++. I want to use Go and Rust. And all the wxWidgets ports to those languages suck, big time. Show me a solid wxWidgets for Rust…
WxWidgets is like React Native but for desktops. It uses the platforms' native UI frameworks. Gtk on Linux. Audacity the audio editor uses WxWidgets.
Earlier quoted context omitted.
>> Would it be good enough on platforms like iOS to dynamically link, include the DLLs in the bundle, and tell people they are on their own if they want to switch them out? You also have to offer them source code, or just ship it along with.
Doesn't the LGPL exempt linking from the "viral" nature of the GPL?
Earlier quoted context omitted.
The HWND-based ones that come with Windows would be the native controls as this is how the underlying window system works. The WPF/UWP/etc UI stacks are built on top of HWND stuff pretty much the same way as Java Swing or JavaFX were made that largely (especially the latter) ignore the underlying window system. Of course since they come with the OS you might as well use those instead of bundling a separate UI toolkit…
UWP is most definitely not HWND per control, and doing so would be incredibly limiting. I don't know the UWP (WinUI) internals, but on mac it's generally a CALayer per widget, and Core Animation is doing the compositing. On Windows, the Windows 8 equivalent is DirectComposition, but I think the WinRT Windows.UI.Composition interface has some capabilities not exposed through winapi.