This will be needed for embedding - to avoid creating two window
adapters - and it will be needed for the API to allow creating a
component from an existing window.
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 added functions enable mixing colors and manipulating the opacity
of colors and brushes.
They enable the behavior of some of the available functions from SASS and are
added for future use for adding the Adwaita style (future PR).
In the compiler this is still very primitive, but an attempt to start a
generic interface. The basic assumption is that all item functions will
eventually need access to the window adapter and itemrc. Support for
additional arguments is still missing.
Also missing is support for the function access via rtti in the
interpreter, hence the hardcoding at the moment.
In the screenshot tests this works by setting SLINT_DEFAULT_FONT to
pointer to a directory, instead of a file. We then load all fonts in
that directory and consider their families the default unless a family
is specified. This way for "Noto Sans" a regular as well as an italic
version is registered in fontdb and returned in the list of font
fallback ids. embed_glyphs in the compiler then embeds those variants
and we find them at run-time.
If one declare a `property <int> foo;` in Slint, it will be private by
default, and the getter/setter won't be generated, and it may be
confusing as to why
With this change, it still generate private getter and setter so this
gives a better hint to the developer what the problem is.
Replaces #2170
We cast the result of the body of functions or binding expressions to
the target type via `as _`. When the code contains a return expression,
that works fine, because `return`'s type is the never type, which can be
coerced to a value of any type. However when the return statement is
inside a sub-block, the type becomes `()`, for which the `as _` cast
fails.
Work around this by attempting to detect the situation (return produces
Type::Invalid) and omit the trailing cast.
This disabled about 70 clippy warnings like this one:
```
warning: redundant clone
--> target\debug\build\energy-monitor-7b0492feb1633656\out\desktop_window.rs:44279:37
|
44279 | (if (((r#state . clone ()) . r#previous_state as f64) == (1f64 as f64)) {
| ^^^^^^^^^^^ help: remove this
|
note: cloned value is neither consumed nor mutated
--> target\debug\build\energy-monitor-7b0492feb1633656\out\desktop_window.rs:44279:28
|
44279 | (if (((r#state . clone ()) . r#previous_state as f64) == (1f64 as f64)) {
| ^^^^^^^^^^^^^^^^^^^^
= help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#redundant_clone
```
I get the following clippy errors in the energy monitor:
error: equal expressions as operands to `-`
--> C:\src\slint\target\debug\build\energy-monitor-7b0492feb1633656\out\desktop_window.rs:47254:94
|
47254 | ... (slint :: private_unstable_api :: re_exports :: LogicalLength :: new (((((0f64 as f64) - (0f64 as f64)) as f64) * (((1f64 as f64) *...
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
= help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#eq_op
error: equal expressions as operands to `==`
--> C:\src\slint\target\debug\build\energy-monitor-7b0492feb1633656\out\desktop_window.rs:45382:18
|
45382 | (((0f64 as f64) == (0f64 as f64))) as bool }
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
= help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#eq_op
I am not surprised that the generated code sometimes produces code like
this (even though the other demos do not!), so I went ahead and silenced
these errors.
The operator== reference the struct name, so if there is a
field with the same name, we should disambiguate
Fix tests/cases/issues/name_conflicts.slint that was added in last
commit
Make sure that we return an unsigned for row_count() in C++ and Rust by ensuring an unsigned int model at creation time.
For the interpreter this "worked" by chance as casting a negative floating
number to usize automatically caps at zero, and all values are stored as f64. For safety this patch
applies the same fix though, to be on the safe side.
Fixes#2005
(Unfortunately, we can't make a driver test for this becasue the
behavior with the interpreter is different than with the compilers.
The interpreter errors out, while the compiler should just generate
nothing)
