The compiler was accepting the comparison of types such as color, or
struct, and then later we'd get rust compilation error or interpreter
panic.
Example seen in the crash reporter:
`internal/interpreter/eval.rs:257:35`
```
unsupported Value::Brush(SolidColor(Color { red: 0, green: 0, blue: 0, alpha: 0 })) ≤ Value::Brush(SolidColor(Color { red: 255, green: 0, blue: 0, alpha: 255 }))
```
Note that some code hapenned to compile with rust or C++.
For example, comparison of bool, or anonymous struct (represented as
tuples), or color represeted as int)
So technically this is a breaking change.
But this should be fine as this was not working in the interpreter and
this is a bug fix.
ChangeLog: Slint compilation error for comparison of types that can't be
compared with less or greater operator.
From the v1.11.0 crash reporter:
There is a panic in
`target/x86_64-unknown-linux-gnu/release/build/slint-lsp-8494405be069a534/out/main.rs:115729:64`
```
called `Result::unwrap()` on an `Err` value: Other("Could not initialize any renderer for LinuxKMS <REDACTED: user-file-path> from Skia renderer: Error opening device <REDACTED: user-file-path>: No such file or directory (os error 2)\\nError from FemtoVG renderer: Error reading DRM resource handles: Permission denied (os error 13)\\nError from Software renderer: Error opening device <REDACTED: user-file-path>: No such file or directory (os error 2)\\nNo renderers configured.")
```
That line in the generated file is in
```
115728 │ fn window_adapter_impl (& self) -> sp :: Rc < dyn sp :: WindowAdapter > {
115729 │ sp :: Rc :: clone (self . window_adapter_ref () . unwrap ()) }
```
Relevant backtrace:
```
6 "core::result::unwrap_failed"
7 "slint_lsp::preview::ui::slint_generatedPreviewUi::PreviewUi::new"
8 "slint_lsp::preview::ui::create_ui"
```
So the theory is that user_init need the window for some reason.
(eg, could be needing the scale factor to conver sizes or some other
things that needs the window)
So make sure we do the test before calling user_init
We must take care that all access to property that we consider constant
in global are accessed after the global has been initialized.
So initialize the global before the properties.
Fixes#8375 , #8337
The code would fail to compile because the property would not be seen as
used and would be removed, but not the change callback.
Fixes#8269
Also fix a segfault in the added test because it will initialize the
change callback (and therefore query the properties) because the
SharedGlobal structure is fully initialized.
So we must only initialize the change callback on global after the
SharedGlobal is fully initialized
... by changing the resolution for the `WindowItem` to traverse the
item tree from the current item, instead of going to the window.
This doesn't quite fix#4298 because `rem` resolution is still missing.
That requires the built-in default font size function to be fixed as
well, which is non-trivial.
cc #4298
The layout pass needs to see when going over the layout, that these
properties are set. So inline the element that sets these properties if
they are not set in the base.
Fixes#8091
Conversion from negative float to unsigned is saturating to 0 in rust
and undefined behavior in C++, we should therefore handle the case
properly
Fixes#8222
Adding support for (optional) trailing commas like this:
import {
Foo,
Bar,
} from "foobar.slint";
This way it's more convenient to keep component imports sorted and
leads to smaller diffs when adding more components to the end of the
import statement.
ChangeLog: Allow trailing comma in import statements
Closes#4922
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>
In the test, `reexport.slint` depends on `bar.slint`
When parsing `reexport.slint` we shouldn't clear previously reported
error from previously parsed `bar.slint`. The errors are still there.
We try to only visit the bindings of used property.
The problem is that when we visit the element, not all properties have
been marked as used, yet. We have a chicken and egg problem.
So just visit all bindings even for property we haven't reached.
This is unfortunate that we have to do that, and we'd need a much
deeper analysis to do this properly.
Fixes#8144
By default it's enabled, of course. This property is not only added to
MenuItem, but Menu as well - since they can be nested. It's also
possible to select a disabled item, but it's hard to modify that since
it's logic is written in Slint. You should be prevented from activating
it with a tap or key press at least.
See #7791
We were not visiting properly the MenuItem from
`recurse_elem_including_sub_components_no_borrow`
(`recurse_elem_including_sub_components` was correctly modified before)
Fixes#8090
The tree-sitter test fails because the output contained `ERROR` as it matched this string
Commit cd6f2e2 reformated the .toml, but the 80 char width column is
judged too small to be practical
Add a .taplo.toml file
Also do not split feature array
You can not create this expression manually, but there
is a pass in the compiler that adds it to all set
properties in a compilation run.
All it does is basically associate an id with an expression,
so that we can then in a later step have the interpreter do
something with that information. Apart from that, it tries to
be as transparent as possible.
The LLR lowering removes that expression again, just so we can
be sure it does not end up in the generated live code.
So that we can pass the focus into the container when it first
shows.
I thought this would be super complex to do property! What a
nice surprise:-)
Fixes: #4055
Let further pass materialize them, and most likely remove them anyway.
That way, they can be properly set and read from the rest of the .slint
code.
Fixes#8080
Although std-widgets provides many properties that adapt to the current theme users who would like to go beyond these properties and do theme dependent changes are limited. One option would be to add even more properties to the Palette, however this would potentially bloat the object, it's not obvious what properties users care about and this approach doesn't scale. In many cases developers could simply create their own properties if they knew what the current runtime theme was.
This simple change allows an app to know what the current theme is and present theme appropriate UI's.
... using taplo with default settings
I tried this with 4 spaces indentation, but the patch is almost as
big as this one, so I went with default settings instead as that
is just easier:-)
This does some refactoring to allow builtin item functions to return a
value:
- builtin member functions are no longer BuiltinFunction, but they are
just normal NamedReference
- Move special case for them in the LLR/eval
Right now we always `lock().value()` it which is the equivalent of
`upgrade().unwrap()` in rust, this helps because it keeps the parent
alive when we are calling function in it.
Ideally we should also check that it wasn't deleted, but that's another
issue.
Fixes#7880
Adds methods to change a `string`'s case to lowercase or uppercase.
They use Rust's `to_lowercase` and `to_uppercase` `String` methods.
ChangeLog: Added string.to-lowercase and string.to-uppercase
Closes#7860
