Facilities for syncing data models with widgets

[idanarye]

Many modern GUI frameworks are data-oriented - they render their widgets based on the same application state the business logic uses. They can do so because they implement the widgets themselves (or at least heavily wrap them), so WoAB - which allows direct usage of GTK components - can't do that.

But maybe instead WoAB can somehow assist in syncing the application data with the widgets?

This is a discussion instead of an issue because I don't really know how I want to do it yet. I'm also not sure it should go in the main WoAB crate - maybe it should go in a separate crate (woab-model or something like that?)

[piegamesde]

To be honest, I still don't quite understand how this is even done in plain GTK. As far as I can tell, they use GValue or some other objects, which may be reference shared between UI and logic (think of ListStore and TreeModel, which are data structures that can be represented by a widget and changes reflect in both ways). I know that JavaFX heavily relies on properties and bindings, which is their way to implement (functional) reactive programming. It works great, and I see that GTK offers this as well, but I haven't seen it being used to that extent. (In Gtk, every object has properties and you can add listeners to it, but the "bindings" part – which makes the magic work and effortless – is a bit weak IMO.)

We may also want to have a look at vgtk, which does elm/yew-like state handling. I'm generally really a fan of that concept, but it is rather intrusive, requires a lot of library support and I don't know how well it integrates with GTK.

Personally, I'm still figuring out how to even structure my woab application – especially the state handling part – in non-trivial use cases. My current approach is to simply try things out and see how well they go. If one pattern emerges as a "winner" (for some situations), one may then ask how to encode it into a supporting library.

[idanarye]

To be honest, I still don't quite understand how this is even done in plain GTK. As far as I can tell, they use GValue or some other objects, which may be reference shared between UI and logic (think of ListStore and TreeModel, which are data structures that can be represented by a widget and changes reflect in both ways). I know that JavaFX heavily relies on properties and bindings, which is their way to implement (functional) reactive programming. It works great, and I see that GTK offers this as well, but I haven't seen it being used to that extent. (In Gtk, every object has properties and you can add listeners to it, but the "bindings" part – which makes the magic work and effortless – is a bit weak IMO.)

We are going to need some synchronization either way - the point of using WoAB is to work with Rust values in your actors, and these should be the SSoT - not the GValues. But maybe, instead of using widget methods for syncing, it would be easier to sync with the properties - the API is more uniform so it might be easier for a generic mechanism to work against that.

Personally, I'm still figuring out how to even structure my woab application – especially the state handling part – in non-trivial use cases. My current approach is to simply try things out and see how well they go. If one pattern emerges as a "winner" (for some situations), one may then ask how to encode it into a supporting library.

Me too, and what I'm currently struggling with is syncing the data. Maybe I'll try generalizing things in my project and then export it to WoAB...

[piegamesde]

In my application, I have the problem that the data has a lot of rather complex invariants to manage. I'd like to have a struct with methods managing these at a more high level, and somehow map them to UI.

For example I have a GtkIconview, but my data has more than only images attached to it, and changes on the images and the internal data need to be synchronized. I also have a data structure that is managed through text fields and checkboxes, but the logic when which field or checkbox may be editable is a bit involved.

Also, I'd like to one day offer an undo buffer, which means that I have to somehow mold all data transitions in a system of recordable events.

[idanarye]

This is why I like option 5 - instead of forcing a one-to-one mapping between the low level widgets and your high level state struct, you get to write that translation yourself - with Rust verifying that you haven't left anything out.

Yes - it would be nice if we could generate the entire thing, but with complex state that would require too much annotations which will involve more work and make things more complex than just writing both translations directly.

[idanarye]

I'm pondering about how to store the state:

1. As a plain field in the actor

#[derive(woab::stateful)]
#[stateful(state=state, widgets=widgets)]
struct MyActor {
    state: MyState,
    widgets: MyWidgets,
}

This one is the most obvious but is has a flaw - the user must actively initiate a sync whenever they change the state.

2. As a wrapped field in the actor

#[derive(woab::StateActor)]
#[stateful(state=state, widgets=widgets)]
struct MyActor {
    state: woab::State<MyState>,
    widgets: MyWidgets,
}

woab::StateActor will generate methods for working with the state:

// Read the state:

self.do_something_with_the_state(self.state().field_1);

// Modify the state:
self.mutate_state(|state| {
    state.field_2 = 12;
});

// or even (no sure how I like this option...):
self.state_mut().field_3 = "hi";
// `state_mut()` d'tor kicks in to sync the state

3. Inside its own actor

struct MyActor {
    state: woab::StateActor<MyState, MyWidgets>,
    widgets: MyWidgets,
}

Here state will actually wrap an address to a WoAB implemented actor (which will also have access to the widgets) and allows sending messages to it:

let field_5 = self.state.with(|state| {
    state.field_4 = true;
    state.field_5.to_owned()
}).await;

There is some elegance here, but it greatly limits the usability and has a big overhead.

4. Like option 2, but with generated methods

#[derive(woab::State)]
#[state(actor=MyActor, field=state)]
struct MyState {
    #[state(describing how to connect it to the widget)]
    field_6: f64,
}

struct MyActor {
    state: woab::State<MyState>,
    widgets: MyWidgets,
}

#[derive(woab::State)] will generate methods on MyActor (not on MyState!) - a single .state() method for reading the state and individual setter methods for setting the state:

let field_6_value = self.state().field_6;
self.set_field_6(field_6_value + 2);

I think this is my favorite, as it allows updating individual fields (all the other methods require updating all the fields at once)

[idanarye]

Actually, maybe I should go with the first option but instead of annotating the actor I'll annotate the widgets? Something like:

struct MyData {
    field_1: String,
    field_2: i64,
}

#[derive(woab::WidgetsFromBuilder, woab::Syncable)]
#[syncable(MyData)]
struct MyWidgets {
    #[syncable(|state| state.field_1], property="text")] // Same expression is both getter and setter
    field_1: gtk::Entry,
    #[syncable(
        |state| state.field_2.to_string(),
        |state, value| state.field_2 = value.parse(), // This is a setter because it has two arguments.
        // We shouldn't have to specify the property - we can let WoAB have a default for common
        // widgets.
    )]
    field_2: gtk::Entry,
}

struct MyActor {
    data: MyData,
    widgets: MyWidgets,
}

And it would create methods on MyWidgets for syncing the data:

self.widgets.set_from_data(self.data);
self.data = self.widgets.get_data();

[idanarye]

5. Generate intermediate struct and use it manually

#[derive(woab::WidgetsFromBuilder, woab::SyncData)]
struct MyWidgets {
    #[sync_data(text: String)]
    field_1: gtk::Entry,
    #[sync_data(text: i64)]
    field_2: gtk::Entry,
}

#[derive(woab::SyncData)] would create a new struct:

struct MyWidgetsData {
    field_1: String,
    field_2: i64,
}

And then I could set it with:

self.widgets.set_data(MyWidgetsData {
    field_1: "Hello".to_owned(),
    field_1: 123,
});

And get it with:

let MyWidgetsData {
    field_1,
    field_2,
} = self.widgets.get_data();

Now, this may look like very little sugar over operating the widgets manually, but it has one big advantage - Rust's typechecker will verify that you are not neglecting any field.

[idanarye]

I don't like that I have to use a String in set_data - this is a needless copy of data. But for get_data I can't use &str because the actual data is stored in GTK.

A possible solution is to generate different structs (like Diesel does) - one with Strings and one with &strs.

[idanarye]

Another option is to only get the data into a closure:

self.widgets.get_data(|MyWidgetsData { field_1, field_2 }| {
    self.do_something_with_field_1(field_1);
    self.do_something_with_field_2(field_2);
});

But... this seems less usable...

[idanarye]

I may have misjudged the requirements a bit. I was focused on my current specific usecase, where all the data widgets are input widgets with editable=false. When the user presses an Edit they all become editable=true, and then when they hit a Save button I save the data from all these widgets to a database.

With this design, the same fields are used for both setting the widgets and getting the data from them. But in many scenarios this is not the case - some of these fields are labels or never-editable text entries, and there is no point in including them in the getter.

This can be worked around by using #[widget(nested)] to separate the writable widgets from the readonly ones, but it would be better to allow turning the getter field on and off from the macro attribute? What should be the default?