Issues when setting VecModel property (from callback)

[yanshay]

Hi, In my app I have a set of buttons generated base on a rust VecModel of ButtonData struct, as follows:

    for button-data[idx] in page-data.buttons-data:
      PushButton {
        text: button-data.text; 
        state: button-data.state;
        clicked(button_state) => {
          return root.clicked(idx, "", button_state);
        }
      }

The state property drives the color of the button.
The button also triggers a callback event which is propogated up to the MainWindow and is handled by rust code.
I've built the callback so that rust can return button_state, and the button modifies its own state property based on the return value of the callback as follows (from the button's code).

    touch-area := TouchArea { 
      clicked => { 
        root.state = root.clicked( root.state );
      }
    }

This is working. However it also causes problems later on.

If I later modify the a button's ButtonData in the VecModel from rust (using set_row_data), after the callback changed it's state property, the button's state property arriving from rust doesn't affect the button's color. Other properties, such as button's text, are being altered as expected. It's as if that property got 'disconnected' from the struct data.

The only way I could find to fix that is to remove the button from the VecModel and immediately add a replacement back again, and then it appear to have 'refreshed' the button properties connection to the button (probably because that caused for removal and addition of buttons, maybe full rebuild of all buttons).
Even creating a new button object in rust and setting the row data to the newly created button struct wasn't enough.

So I wanted to ask:

1. Is it wrong to change a property that's driven by a struct/array directly and not through the data source? I thought it would be a two way binding.
2. Maybe it's only not allowed when inside a callback?
3. How can I reach the source of data of the button from the button's code to change the property there? Should the button be aware of the entire structure and reach its own struct? Is it possible to provide it with a reference to its own specific struct?

And another related behavior:
I tried changing the struct state field from slint by changing the top piece of code to change the struct data based on the event return value (instead of in the button):

    for button-data[idx] in page-data.buttons-data:
      PushButton {
        text: button-data.text; 
        state: button-data.state;
        clicked(button_state) => {
          button-data.state = root.clicked(idx, "", button_state);
        }
      }

That worked, but it had another side effect.
Prior to this change, in rust, inside the callback handler, I used set_row_data to the change the text, and it worked.
Now, with this added that change of text didn't take effect, as if altering the button-data here forced using the old button-data.

• Why is that?

[hunger]

Do you have a demo project somewhere I can play around with? It is so much easier to find problems when you can actually see the effects.

I understood that you have a set of "button data" in a model and then create a set of buttons from that. You propagate a field of that button data up to the root element and pass it to rust in a callback. Rust will then replace the matching line in the model with new data, incl. the field you passed up.

That same field is also used to influence the color of the button somehow. I do not understand how that is done though.

The problem is that while the field changes, the color does not update?

The only way I could find to fix that is to remove the button from the VecModel and immediately add a replacement back again, and then it appear to have 'refreshed' the button properties connection to the button (probably because that caused for removal and addition of buttons, maybe full rebuild of all buttons).

Removing/re-adding the row will create a fresh Button, while changing the data in an existing field should just cause the data to be updated in the existing button. So this looks a bit like you are changing the binding after the fact, maybe from the rust side or from code around the callout to rust?

What exactly do you do there?

[yanshay]

Do you have a demo project somewhere I can play around with? It is so much easier to find problems when you can actually see the effects.

I'll try to build a simple demo to reproduce the issue. I think it can even be demonstrated with pure slint.

The problem is that while the field changes, the color does not update?

The problem is that after I change the control property on the control directly (so not by changing the struct) and the color does change, further changes to the struct don't change the property (but do change other properties).
Also when I replace the struct (from struct) that binding to the struct isn't refreshed either.

[yanshay]

Here is code example demonstrating the issue, pure slint:

import { Button } from "std-widgets.slint";

struct ButtonData {
  txt: string,
  state: int,
}

export component PushButton inherits Rectangle {
    in property <string> text <=> label.text;
    in-out property <int> state;

  background: root.state == 1 ? #ff0000 : 
              (root.state == 2 ? #00ff00 : 
              (root.state ==3 ? #0000ff : 
              (root.state == 4 ? #888888 : 
              (root.state == 5 ? #ffff00 : 
               #005555))));
    
    callback clicked;

    border-radius: 13.5px;

    label := Text {
        font-size: 18px;
        color: #ffffff;
        horizontal-alignment: center;
        vertical-alignment: center;
    }

    touch-area := TouchArea { clicked => { root.clicked() } }
}

export component AppWindow inherits Window {
    width: 320px;
    height: 240px;

    in-out property <[ButtonData]> buttons-data: [
       { txt: "Button1", state: 1 },
       { txt: "Button1", state: 2 },
       { txt: "Button1", state: 3 },
      ];
  
    VerticalLayout {
      for button-data[idx] in buttons-data:
        HorizontalLayout {
          pb:= PushButton {
            text: button-data.txt;
            state: button-data.state;
          }
          Button {
            text: "Propery Change -\{idx+1}";
            clicked => {
              pb.state = 4;
            }
          }
          Button {
            text: "Data Item Change-\{idx+1}";
            clicked => {
              button-data.txt = "Data Changed";
              button-data.state = 5;
            }
          }
      }
      for i in [1,2,3] :
        Button {
          text: "Array Row Replace-\{i}";
          clicked => {
            buttons-data[i - 1] = {
              txt: "Array change",
              state: 6,
            }
          }
        }
    }
}

1. When pressing 'Property Change' buttons - state only (affecting color) is changed by direct access to the property.
2. When pressing 'Data Item Change' both text and state change by changing the data item.
3. When pressing 'Array change' both text and state change by replacing the data item.

After pressing "propery change" the other changes don't affect the state any longer.
This means a control can't change it's own properties while still allowing external struct change to affect its properties.
I thought the binding would be two way, so if a control change it's bound properties it would also change the data.
And the 'Array change' I'd expect to force overriding that property change since its replacing the array row altogether.

[hunger]

Oh, thank you for the example, that makes things much clearer to me!

There is just a normal binding, so the "Property Change" button rebinds the PushButtons state to a fixed value of 4. A normal binding is what you asked for here:

          pb:= PushButton {
            text: button-data.txt;
            state: button-data.state;
          }

Caveat: When you change that to state to use a two-way binding using <=>, you will get an error that this is not supported yet;-) It would be cool to support that for exactly your use case though!

The advantage is that a simple binding allows to "unbind" the model data from properties again.

Your example works (I think) when you change:

          Button {
            text: "Propery Change -\{idx+1}";
            clicked => {
              button-data.state = 4; // instead of: pb.state = 4;
            }
          }

That change should be fine for you: You wanted the assignment to pb.state to change the bound value in the model anyway :-)

[yanshay]

Your example works (I think) when you change:

That` change should be fine for you: You wanted the assignment to pb.state to change the bound value in the model anyway :-)

Yes, that's what I did in the "Data-Item change" buttons there.

The issue with that solution that I can't do that from within the PushButton code, only from its container who has access and is aware of the button-data. So I can't have state related functionality inside the button and the container has to cooperate with that. I think there are cases where this is painful, need the container implement logic that should be inside the controls.
But I get this is a limitation now.