3 ms·
The usual way to do event handling in Rust is to either expose an event loop directly, or use an async toolkit where you have multiple components, each owning t
by vertex-four 10y ago
The usual way to do event handling in Rust is to either expose an event loop directly, or use an async toolkit where you have multiple components, each owning their own subset of data and processing events related to it, talking to each other over channels, futures, or some other abstraction.
Closures are difficult to use for this due to Rust's concept of values having one owner, making it fiddly to share values over multiple closures without e.g. wrapping them in Rc<RefCell<T>>.
- pcwalton 10y ago> Closures are difficult to use for this due to Rust's concept of values having one owner, making it fiddly to share values over multiple closures without e.g. wrapping them in Rc<RefCell<T>>. But note that most UI toolkits already effectively expose all their objects as reference-counted aliasable-mutable—the same as Rc<RefCell<T>>, but more ergonomic. I wonder if the right solution for this for these frameworks to allow programmers to easily create their own classes in the native widget class hierarchy (COM, Objective-C Foundation, GObject, QObject, etc.), with some combination of macros and other boilerplate generation. Then the rule would effectively be "instead of using Rc<RefCell<T>>, create a native widget class to hold your data if you need to multiply close over it". Not only would this be more ergonomic than the pure-Rust solution, but it'd also interoperate better with the underlying widget system: for example, on macOS and iOS Objective-C introspection APIs would work with such objects.
- vertex-four 10y agoThe issue is less the UI toolkit data and more all the other data in your app.
- pcwalton 10y agoThe solution I proposed is for all that other data.