-
Notifications
You must be signed in to change notification settings - Fork 555
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conditional item gets re-instantiated even if the result is the same #3953
Comments
It seems that due to re-evaluation of the binding, the MainContent got re-instantiated, causing it to switch back to the Portfolio page each time the Facade.portfolio was set. See slint-ui/slint#3953
The thing is that we have to reset the whole thing if the model is dirty in Lines 871 to 872 in c695869
But we could actually check if the model has changed before doing that. Now the problem is how to compare two model. Because the generated expression in rust is |
Or maybe it is possible to do a special case check for comparing |
If resizing makes the value of is-resizable dirty, we would hit issue #3953 and the handle would be re-created and the drag operation aborted
If resizing makes the value of is-resizable dirty, we would hit issue #3953 and the handle would be re-created and the drag operation aborted
I just came across this issue after updating an older private project; this seems to be a recession from 1.2.2 to 1.3.0. In my case, I had a conditional button in a video-player-like application, which is almost impossible to click because the player state is updated 60 times a second:
I could workaround this issue by "pulling the ifs inside":
|
Platform: Linux / winit / FemtoVG / X11, Language: Rust
Consider the following code:
When I call
facade.set_portfolio
, theMainContent
appears to be always re-instantiated (judging by the loss of its state), even if the result of the condition staystrue
. This is undesirable.I'm working it around in my application by instead doing:
But this of course keeps the instance around, even when it is not needed.
The text was updated successfully, but these errors were encountered: