In 80de96488a (#3397) we introduced a new
error if we detect a binding loop from the Window geomerty to its layout.
But it looks like this causes a lot of error in existing project, so
make it a warning instead.
It will continue to be an error in the live preview as this will cause a
panic otherwise.
This commit also change the text of the error to include the actual
binding loop. I hope this makes it easier for users to see the loop and
help to fix it.
* syntax_tests: allow to "bless" tests, and don't use a regexp
A regexp was used at the beginning because I thought we would want to
allow error to contains things that were not predictable or that would
often change. But this is not the case¹. It is better to actually test
for the full error message
¹ well actually it was the case for path, but there is another substitution to
`📂` for the manifest directory
* syntax_tests: Bless the tests
* syntax_tests: Manual adjust after bless
Because there used to be comments on the same line of the message which
bless don't support
* Fix error message with path on windows
- The debug implementation of path make double slash, that's not what
we want to show the user
- normalize paths to use `/` so the test passes
This is only exposed when internal types are exposed (such as in the lsp).
The plan is to make this public under a new name/global after the release.
Co-authored-by: Olivier Goffart <olivier.goffart@slint.dev>
Instead of panicking.
Attempt to fix it in #6765 didn't work for C++.
Code generation might be hard for C++, so I thought it's better to error out.
Fix#6760
And use that in the lsp/ui implementation instead of comments.
This is only a parser support for now, the name is otherwise unused.
Hence I rather keep that experimental.
Updated the version from 1.1 to 1.2
Renamed the header to "Slint Royalty-free Desktop, Mobile, and Web Applications License"
Added definition of "Mobile Application" and grant of right
Moved "Limitations" to 3rd section and "License Conditions - Attributions" to 2nd section
Added flexibility to choose between showing "MadeWithSlint" as a dialog/splash screen or on a public webpage
Moved the para on copyright notices to section under "Limitations"
The problem is that we were taking the whole `repeated` field and as a
result we wouldn't see that the element was being repeated and that we
shouldn't have to lookup id within it
Fix#4683
Some property need to be known at compile time. We already had checks
that the binding is a compile time constant, but there was no check to
prevent, say
self.row = 42;
which wouldn't work or could even cause panic or miscompilation of
generated code
Closes#4037
Regression noticed in this line:
3f97d98bff/ui/tabs/downloads.slint (L77)
The following used to work:
```slint
import { Button, VerticalBox } from "std-widgets.slint";
export component Demo {
in property <[int]> mods;
VerticalBox {
alignment: start;
for xxx in true ? mods : [] : HorizontalLayout { alignment: center; Button { text: "OK!"; } }
}
}
```
But we fixed array conversion and this caused a regression with empty
array
Fixes#3085
When there are both a binding and a two way binding, we must keep the
two way binding in our bindings map. Otherwise type inference will not
work
That way the error for an expression is at a better location, and
this also prevent the formater that removes space in expressions to
remove the spaces before the expression that shouldn't be removed
Some binding can't be express with the current data structures because
they reference propertis within inner elements within a component.
The fix is a bit involved and the best is to have an error istead of a
panic, for now.
Because of issue #1394 and because the semantic are not properly defined
currently, we decided that future version of slint should always and only
take the binding from the right hand side, even if it has no bindings.
Since we can't change the behavior in 0.2, just add a warning instead for now.
The warning can be silenced by setting a default binding for the property on the rhs.
Ignoring the warning can still lead to panic (the one in #1394)