11–20 of 149 posts
One thing I'd like to see are Rust bindings for wxWidgets. Contrary to the prevailing opinion, I think wrappers over native toolkits are a fine approach for cross-platform development.
One thing I'd like to see are Rust bindings for wxWidgets. Contrary to the prevailing opinion, I think wrappers over native toolkits are a fine approach for cross-platform development.
Writing effective cross-platform application is harder than one would think. Some time ago there was a discussion on HN where a WxWidgets maintainer stepped in to explain why some WxWidget programs were apparently inconsistent across O/S, and the explanation was that they were developed naively (I think one needs to use specific spacing abstractions, but I don't remember with exactness).
For my personal development, I use non-native (which is easier to develop), however, on large scale, it'd be a tough decision.
WxWidget was my favorite in the past (again, for personal development), however, the bindings are very spotty, which prevents adoption for several languages (wiki page: https://en.wikipedia.org/wiki/List_of_language_bindings_for_...).
Sadly Rust for WinUI3/UWP/XAML for Windows GUI - actually modern UIs on Windows - was abandoned or explicitly removed from Rust API bindings by MS. The listed library only uses the ancient win32 api
Sadly? I prefer desktop Windows programs to be gdi/win32, they are often the most thought out and optimized for actual desktop paradigms (i.e mouse+keyboard+high res screen) without giant margins, padding and whitespace everywhere and makes use of proper desktop class widgets like treeviews, listviews, tabs, etc.
Started life as a rendering layer for FlowBetween so I could put in whatever looked like it was 'winning' later on but wound up writing my own renderer as there wasn't anything quite there yet. Still has that design so another unique thing is that it's possible to use the same API with whatever rendering layer you want.
Speaking of FlowBetween, one thing I have wanted to do for ages is to get rid of the platform-specific GUIs and use something universal. It should be easy because FlowBetween sends straightforward instructions to an independent GUI layer, but I keep bouncing off for a few reasons:
- it's a big ole task so I definitely want to pick something that's stable and also lets me hedge my bets in terms of being easy to migrate away from
- most commonly, FlowBetween needs pressure data from tablets and a lot of frameworks just don't do that (this is also in a terrible state in browsers)
- lots of GUI crates are designed as frameworks and so try to dictate the entire design of any app that uses them, which is no good for FlowBetween which tries to keep its internal design choices independent of its choice of GUI
At the moment, I suspect that some sort of imgui framework is best along with an entirely manual implementation of tablet pointer data: fits with my existing design and isn't 'contagious' in a way that could make it hard to migrate to something else later on.
How many of those actually look and behave like native and support accessibility correctly?
How many of those actually look and behave like native and support accessibility correctly?
How many of those actually look and behave like native and support accessibility correctly?
What even is "native" on Windows? Is it Win32? WinForms? WPF? UWP? WinUI? Windows App SDK? There's so many to choose from and they all look and behave differently.
How many of those actually look and behave like native and support accessibility correctly?
It seems Rust will be famous for the number of GUI libraries.