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
* Extend the cspell word list
* Remove those extensions from individual source files
* white-list licenses and such as we should not meddle with those
* Fix spelling
This should in principle not be allowed, it should be relative to the
file itself.
Make it a warning, and at least, don't duplicate the globals
Fixes#2719
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
This improve the code coverage of syntax_text, so some adjustment had to
be made.
This may add more error in the main file, but this make it the same
behavior as for imported files and lsp who were already running these
passes all the time
Since we materialize only one point property, we don't need to cache the
parent position in a separate property, but we can just store that in
the binding.
The type of thep property is `Point`, which existed before. It was
mapped to `slint::private_unstable_api::re_exports::Point` (euclid) and
is now mapped to slint::LogicalPosition (also in C++).
This patch adds a `close()` function that can be called to close a popup
window, and a `close-to-click` boolean that can be set to false to
disable the default behavior.
The old parser always try first to find `Foo :=` from the old syntax so it
would error saying it expect an identifier or `:=`
But if we don't find a component, don't try to parse it as a component too early
This way we get better error and better auto-completions
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
Just like opacity and other properties, it needs to prevent inlining.
And also add the same warning as for opacity if it is used on the root
(the Window)