You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
To test you can just open SlintPad, and verify that it works, than save that file and open it on local machine with slint-viewer and verify that it doesn't work, uncomment the line, it will work.
Conclusion:
Is this a bug, or a skill issue? In any ways it is weird that the behaviour is different.
It looks like some update dependency isn't being set when it should, or in reverse.
APPENDIX 1:
What I actually wanted is to move out Node from the loop into its own definition, but than there is a different problem with
two-way bindings not supported, may be related here? That seems to only be implementable by passing whole array and index as properties, which is annoying. if you have idea on how to do it in a different way please say.
APPENDIX 2:
Actually after looking into I think the issue is that one way binding acts like a two way binding on cargo run and slintpad?
Here is the link: SlintPad weird example 2
You see, it has nodes: nodes; there right, so in the slintpad it propagates the modified state to the parent, but in the slint-lsp it doesn't, when you change it to nodes <=> nodes; then it works in both.
The text was updated successfully, but these errors were encountered:
Background:
I've been implementing node graph, with code based on this: #3608 (comment)
And there seems to be this one line:
nodes[idx] = n;
, the problem occurs when you remove it.Problem:
Basically in slint-lsp or slint-viewer when you try to move Node then Link attached to it doesn't update, it looks like this:
But when you try to move it in the slintpad or in the compiled rust project with slint builder it looks like this:
Expected:
Both behave the same, I expected the second outcome.
Test:
[SlintPad preview]
To test you can just open SlintPad, and verify that it works, than save that file and open it on local machine with slint-viewer and verify that it doesn't work, uncomment the line, it will work.
Conclusion:
Is this a bug, or a skill issue? In any ways it is weird that the behaviour is different.
It looks like some update dependency isn't being set when it should, or in reverse.
APPENDIX 1:
What I actually wanted is to move out Node from the loop into its own definition, but than there is a different problem with
two-way bindings not supported, may be related here? That seems to only be implementable by passing whole array and index as properties, which is annoying. if you have idea on how to do it in a different way please say.
APPENDIX 2:
Actually after looking into I think the issue is that one way binding acts like a two way binding on cargo run and slintpad?
Here is the link: SlintPad weird example 2
You see, it has
nodes: nodes;
there right, so in the slintpad it propagates the modified state to the parent, but in the slint-lsp it doesn't, when you change it tonodes <=> nodes;
then it works in both.The text was updated successfully, but these errors were encountered: