Property Changed Callback in Slint

[ogoffart]

Discussion for the blog post: https://slint.dev/blog/property-changed-callback

[N4tus]

If property-changed-callbacks are added, that looks to me like an unfinished signals-like system. Why not go the full route and add proper derived values and effects.
Specifically the property-changed-callbacks that manipulate another property should probably be a derived value instead.

[ogoffart]

Thanks for your explanations. I understand better now.
And yes, this indeed transform any property that has a changed callback as a "leave" as the evaluation will be forced. This is indeed a drawback.
Do you have a suggestion on concretely what we could change to improve this?

[N4tus]

And yes, this indeed transform any property that has a changed callback as a "leave" as the evaluation will be forced.

This was very surprising to hear. I would have expected to calculate all derived values first and only once they are all calculated run any value-changed callback. Again semantically speaking, the calculation can still be lazy, but from the outside it seems (modulo side effects during derivations) like all value-changed callbacks are evaluated later. This is sometimes called a pull reactive model.
This would mean that value-changed callbacks cannot be used to verify the validity of a property. The example uses that to keep the range of an property<int> between 0 and 100. To do something like that slint would need another solution.

You could provide a way to separate property-read from property-write. Then the write-half could check that the values are correct/correct the values before applying them. A lot of other frameworks physically separate these halves (This react-style [value, setValue] = useState). But I don't think this is really necessary for slint. A custom setter for properties would be enough. Whenever a property with a custom setter receives a new value, that setter is responsible for handling it. However allowing that setter to ready other properties would complicates some things (E.g. the max-value is stored in another property, so that it can be configured from the outside). To do that all properties, from the setter and for the actual value, need to be considered both as dependencies. Doing that is not terribly complicated but having multiple locations that declare dependencies makes it easier to accidentally create a dependency cycle.

component Spinner {
    in property <int> max;
    in-out property <int> value: 0
    set v => {
        f (v < 0 || v > max) {
            // using the name of the property suggests that you can write to other properties using their names. But you can't.
            self = v.clamp(0, max);
        }
    };
}

Now this looks almost like the value-changed callback. The difference is that it immediately runs on any assignment of the property and is supposed to manage the value, where a value-change callback does not manage any values, can easily read other properties (I would not even tie it to only one specific property) and runs after rendering happened.

[bjorn]

I agree having a "setter" is the more obvious way to apply bounds. In Qt Quick, such things are trivially available because the items are implemented in C++ where functions like QQuickSlider::setValue can do this.

While the concept of setters could be introduced to the Slint language, I'm rather wondering whether this type of logic belongs there at all. What's even the point in limiting a slider's value to its bounds? Because:

• The slider's implementation is not expected to ever set the value outside of its bounds (in the provided example, a (possibly internal) setter was really the only thing necessary).
• If the value is set out of bounds externally, the slider's implementation can handle that any way it wants. If it's easier to visualize the slider with a bounded value, it can be trivially added with an internal property. Changing the value to be within the slider's bounds might not be desirable at all.

But, maybe it was just a bad example? It doesn't appear that particular one is "difficult to do" without changed callbacks except if we want the SpinBox to police its user. It might help to focus on use-cases without obvious alternatives, like the mismatch between the has-hover property and PopupWindow API needing function calls (see #4395 and #1617) (though even there, it's not clear to me whether change callbacks are the right solution... it might be better to introduce a way to bind visible: touch.has-hover (but there is no PopupWindow.visible property at the moment) or add the missing leave/enter mouse events so they can be routed to show/close).

Overall we must be careful not to introduce property change callbacks to solve all kinds of issues that could have been better solved in other ways.

[N4tus]

What's even the point in limiting a slider's value to its bounds?

If you have a Slider that is limited to 100, I would be puzzled when reading a value that is larger. But you are right that there are also other ways to achieve something like this. For example:

component Spinner {
    in property <int> max = 100;
    in property <int> value = 0; 
    out property <int> valid_value = value.clamp(0, max);
}

This essentially splits the value in two halves one read-halve valid_value and one write-halve value. The downside is that users have to remember how these two halves are related. But since these are now separate properties you cannot easily two-way bind a property from your backend to the ui.

With regards to #4395 and #1617 I think an proper effect would nicely solve these issues. And I want the value-changed effect to be a proper effect.

[tronical]

The reactive model of Slint becomes primarily alive when rendering (producing pixels). So say when rendering a frame and visiting a rectangle, its background property is read to determine the brush to use to fill it. This is when the binding for the property will be evaluated, and subsequently any dependent bindings.

React can "render" by mutating the DOM but because those changes aren't immediately visible, any effect functions invoked can make additional changes before the rendering engine of the browser truly produces pixels.

A true effect system in Slint would collect all of the properties needed to rendering, and then invoke change callbacks (our effects), and then finally produce pixels with the result.

[Artxiom]

From my experience with property changed callbacks in Qt:

They can be super useful but also are terrible for one of their main tasks — and this shows up surprisingly often and was never truly addressed by Qt: two-way synchronization with the backend (aka app-core, in C++ for example, not server).
Usually we always had some core/model written in C++ with an Qml UI layer and needed to update the model from the UI, but also the UI from the model. There is also not really any way to make this one-way, as sometimes the data can come from the network, filesystem, etc., and thus update the UI.

This just doesn't work well with property changed callbacks because they are one-way in nature. So you end up either separating the callbacks by source (valueChangedByInput, valueChangedByModel) — which works surprisingly well, but we needed to duplicate a lot of Qt components because of that (they don't differentiate between multiple sources) or you have to write some declarative layer, like a TwoWayBinding — and this is surprisingly complex and in the end you also end up with two callbacks.

So if I would have to design such a system from scratch I would definitely separate values/state and events. This effectively gives you three property changed callbacks (state changes, value changed by component (=input), value changed from the "outside").
Sounds like a lot but values need to be very often (if not most of the time) transformed and processed differently based on the event that generated them and not on the value alone.

Have you also considered to go for a reactive system like rxRust for example? This is way more flexible and powerful than callbacks (and also easier in the long run imho).

[ogoffart]

Thanks for your comment. This indeed relate to my experience as well.

We do use a reactive system internally. We have an implementation of a Property which is serving the same purpose as what rxRust does.

We also do have two way bindings with <=>, but it is only working if both properties have the same type, which is not always the case when you want to synchronize properties.