Kudos for the author for sticking with it through so many libraries. I’ve only been watching from the sidelines with curiosity since I don’t actually write Rust, but might be convinced if the...
Kudos for the author for sticking with it through so many libraries.
I’ve only been watching from the sidelines with curiosity since I don’t actually write Rust, but might be convinced if the right UI library came around. Unfortunately it seems like it’s still struggling on the UI front.
Is there a reason why all of the libraries that aren’t wrappers around something else are declarative? I think that might be part of the issue. UI frameworks in the vein of SwiftUI require a lot of “magic” to make work and are difficult to get right, particularly for more advanced use cases where widgets as provided out of the box aren’t adequate. Have there been any attempts at a pure Rust old style imperative UI framework? Those aren’t trendy but are easier to get right.
My conjecture is that writing a new imperative UI framework just isn't worth the effort vs creating bindings to an existing framework. New frameworks need some hook especially when competing...
My conjecture is that writing a new imperative UI framework just isn't worth the effort vs creating bindings to an existing framework. New frameworks need some hook especially when competing against well established systems.
Separately rust's reference rules probably push towards avoiding shared state or at least obscuring it from developers. Imperative UI code often has a lot of mutable references being accessed from a wide variety of locations
For me a big enough hook would be for this hypothetical new imperative UI framework to be easy write bindings for (has C headers, basically) and instead of doing the usual lowest common...
For me a big enough hook would be for this hypothetical new imperative UI framework to be easy write bindings for (has C headers, basically) and instead of doing the usual lowest common denominator thing did the opposite. So for example, the macOS/AppKit standard miller column widget would be present and usable on all supported systems instead of just being missing like it is in current cross platform frameworks.
Those are my two biggest gripes with the current options. Most have a limited set of widgets, and those with the least limited sets instead are only practically usable with a tiny handful of languages.
Rust referencing rules being a problem makes sense.
Kudos for the author for sticking with it through so many libraries.
I’ve only been watching from the sidelines with curiosity since I don’t actually write Rust, but might be convinced if the right UI library came around. Unfortunately it seems like it’s still struggling on the UI front.
Is there a reason why all of the libraries that aren’t wrappers around something else are declarative? I think that might be part of the issue. UI frameworks in the vein of SwiftUI require a lot of “magic” to make work and are difficult to get right, particularly for more advanced use cases where widgets as provided out of the box aren’t adequate. Have there been any attempts at a pure Rust old style imperative UI framework? Those aren’t trendy but are easier to get right.
My conjecture is that writing a new imperative UI framework just isn't worth the effort vs creating bindings to an existing framework. New frameworks need some hook especially when competing against well established systems.
Separately rust's reference rules probably push towards avoiding shared state or at least obscuring it from developers. Imperative UI code often has a lot of mutable references being accessed from a wide variety of locations
For me a big enough hook would be for this hypothetical new imperative UI framework to be easy write bindings for (has C headers, basically) and instead of doing the usual lowest common denominator thing did the opposite. So for example, the macOS/AppKit standard miller column widget would be present and usable on all supported systems instead of just being missing like it is in current cross platform frameworks.
Those are my two biggest gripes with the current options. Most have a limited set of widgets, and those with the least limited sets instead are only practically usable with a tiny handful of languages.
Rust referencing rules being a problem makes sense.