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
The current syntax works and is very declarative, but it is kinda verbose. There are several strategies one can find to fix this problem.
One strategy is to simply add more helpers such that some common cases can be come more terse and require less construction of Qt objects. I like the idea of requiring less QObjects a lot, so for example, we could try rewriting this:
Note that declaring variables like that is already possible (they don't need to be in the solver). I am not sure whether it's a good idea or not. It depends on whether you want/need to expose them to the outside world.
A nother intersting approach, but less QML-ish, would be to use strings instead and parse the expressions, like this:
In this later case, the API would need a major revamp, such that one could access the values of these string-identified variables. It lso becomes more tricky to inject values that come with QML, since one need then to manipulate the string somehow, and it might perform worse if constraints change often (which they should not anyways, but...).
The text was updated successfully, but these errors were encountered:
The current syntax works and is very declarative, but it is kinda verbose. There are several strategies one can find to fix this problem.
One strategy is to simply add more helpers such that some common cases can be come more terse and require less construction of Qt objects. I like the idea of requiring less QObjects a lot, so for example, we could try rewriting this:
As:
Note that declaring variables like that is already possible (they don't need to be in the solver). I am not sure whether it's a good idea or not. It depends on whether you want/need to expose them to the outside world.
A nother intersting approach, but less QML-ish, would be to use strings instead and parse the expressions, like this:
In this later case, the API would need a major revamp, such that one could access the values of these string-identified variables. It lso becomes more tricky to inject values that come with QML, since one need then to manipulate the string somehow, and it might perform worse if constraints change often (which they should not anyways, but...).
The text was updated successfully, but these errors were encountered: