5 ms·

Can anyone briefly describe or point to the relevant resource - how GUI toolkits in Rust are done without the proper OO? E.g. how do you model and implement Obj

by zerr 5y ago

Can anyone briefly describe or point to the relevant resource - how GUI toolkits in Rust are done without the proper OO? E.g. how do you model and implement Object > EventHandler > Window > Control > RadioButton hierarchy?

gpm 5y ago
I mean, for gtk in particular, I think they just implemented everything necessary to make rust understand and interact with gobjects "proper OO" hierarchy, which gtk is built on top of. Rust isn't natively OO, but neither is C... There are some examples of OO rust in the documentation here for instance: https://gtk-rs.org/gtk-rs-core/stable/latest/docs/glib/subclass/index.html https://gtk-rs.org/gtk-rs-core/stable/latest/docs/glib/subcl... Or you can look at the repository linked in this HN submission as a practical example... --- Outside of the OO-gtk world, there's been quite a bit of experimentation with non-OO gui systems in rust, but I don't think there's a settled "best design" yet. Many designs look something like the following - model: rust struct describing your data - view: function mapping your data to widgets, widgets understanding how to layout, render, and issue commands - commands: events in view generate simple command structs - update fn: iterates over commands, updating model With the framework passing input to widgets, and taking commands from the widget and passing them to the update fn, and then calling view to update widgets. Potentially intelligently to avoid redundant work (e.g. not re-rendering widgets that haven't changed). The bigger constraint driving this than "not-OO" is "not mutably aliasing data". You probably don't want to try and have your update functions take a mutable reference to your model, because you will end up fighting the borrow checker. (On the other hand, I think egui does manage to pass mutable references to the model to callbacks, so maybe this is just a reflection of the rust gui's I've personally experimented with) So in a slightly imaginary reasonably representative gui framework, I might have struct Model { chickens_can_fly: bool } enum Command { ToggleChickensCanFly } fn view(model: &Model) -> impl Widget { CheckBox { checked: model.chickens_can_fly, on_change: || Command::ToggleChickensCanFly } } fn update(model: &mut Model, command: Command) { match command { Command::ToggleChickensCanFly => model.chickens_can_fly = !model.chickens_can_fly } }
- gattr 5y ago
  In my small project ([1], Rust + GTK3) I pass the program state wrapped in Rc<RefCell> to my update functions (closures-as-event-handlers) and so far it's been OK (after all they're executed sequentially from the main thread only). One just needs to remember not to hold the borrow when displaying a message box (as in GTK it enters a new message loop recursively). [1] https://github.com/GreatAttractor/vidoxide https://github.com/GreatAttractor/vidoxide
int_19h 5y ago
Rust has something akin to inheritance for traits. There are no up/down/cross-casts, but these can be done as methods in hierarchies where they are actually needed.
kzrdude 5y ago
OO is a pattern, not (necessarily) a language feature. As already mentioned, GTK is implemented in C, which has "similar" starting point for OO as Rust.
- zerr 5y ago
  GTK uses Glib which implements the whole OO manually. I'd expect something different in the modern language.
  - kzrdude 5y ago
    The 1990s was the decade of the OO hype culmination (Java, C++), and Rust is designed after that ended :)
    - zerr 5y ago
      But one would expect something different (better) than "back to C, lets implement vtables by hand" :) Procedural programming hype was in 70s/80s, but that doesn't mean we got rid of procedures afterwards :)

by zerr 5y ago

gpm 5y ago

I mean, for gtk in particular, I think they just implemented everything necessary to make rust understand and interact with gobjects "proper OO" hierarchy, which gtk is built on top of. Rust isn't natively OO, but neither is C... There are some examples of OO rust in the documentation here for instance: https://gtk-rs.org/gtk-rs-core/stable/latest/docs/glib/subclass/index.html https://gtk-rs.org/gtk-rs-core/stable/latest/docs/glib/subcl... Or you can look at the repository linked in this HN submission as a practical example... --- Outside of the OO-gtk world, there's been quite a bit of experimentation with non-OO gui systems in rust, but I don't think there's a settled "best design" yet. Many designs look something like the following - model: rust struct describing your data - view: function mapping your data to widgets, widgets understanding how to layout, render, and issue commands - commands: events in view generate simple command structs - update fn: iterates over commands, updating model With the framework passing input to widgets, and taking commands from the widget and passing them to the update fn, and then calling view to update widgets. Potentially intelligently to avoid redundant work (e.g. not re-rendering widgets that haven't changed). The bigger constraint driving this than "not-OO" is "not mutably aliasing data". You probably don't want to try and have your update functions take a mutable reference to your model, because you will end up fighting the borrow checker. (On the other hand, I think egui does manage to pass mutable references to the model to callbacks, so maybe this is just a reflection of the rust gui's I've personally experimented with) So in a slightly imaginary reasonably representative gui framework, I might have struct Model { chickens_can_fly: bool } enum Command { ToggleChickensCanFly } fn view(model: &Model) -> impl Widget { CheckBox { checked: model.chickens_can_fly, on_change: || Command::ToggleChickensCanFly } } fn update(model: &mut Model, command: Command) { match command { Command::ToggleChickensCanFly => model.chickens_can_fly = !model.chickens_can_fly } }

gattr 5y ago
In my small project ([1], Rust + GTK3) I pass the program state wrapped in Rc<RefCell> to my update functions (closures-as-event-handlers) and so far it's been OK (after all they're executed sequentially from the main thread only). One just needs to remember not to hold the borrow when displaying a message box (as in GTK it enters a new message loop recursively). [1] https://github.com/GreatAttractor/vidoxide https://github.com/GreatAttractor/vidoxide

int_19h 5y ago

Rust has something akin to inheritance for traits. There are no up/down/cross-casts, but these can be done as methods in hierarchies where they are actually needed.

kzrdude 5y ago

OO is a pattern, not (necessarily) a language feature. As already mentioned, GTK is implemented in C, which has "similar" starting point for OO as Rust.

zerr 5y ago
GTK uses Glib which implements the whole OO manually. I'd expect something different in the modern language.
- kzrdude 5y ago
  The 1990s was the decade of the OO hype culmination (Java, C++), and Rust is designed after that ended :)
  - zerr 5y ago
    But one would expect something different (better) than "back to C, lets implement vtables by hand" :) Procedural programming hype was in 70s/80s, but that doesn't mean we got rid of procedures afterwards :)