In code-blocks, only the final expressions value is actually used. All
other expressions must have side effects or are otherwise useless.
This usually indicates an error by the programmer, so emit a warning to
notify the programmer about the issue.
Closes#4954
Example from the associated issue:
This Slint code
```slint
FocusScope {
key-pressed(event) => {
if (event.text == "a") {
accept
}
reject
}
}
```
Looks like it would return accept, but in fact, the statement has no effect.
Changelog: The slint compiler now emits a warning if a statement is without effect
Clarify that for example rowspan and colspan are to be used in a cell. Case in point:
```
GridLayout {
rowspan: 2;
```
shouldn't say that "rowspan" can't be used in a GridLayout when it's used in a grid layout :)
When an item in a grid layout specifies row or col, this property is no
longer removed by the compiler.
That's the one liner that changes removes() with get(), but the side
effect of that is that the code that checks that no row/col/etc.
property is still there afterwards (to give compile-time errors)
had to be improved to check if this is an item inside of a grid layout,
since the property stays now.
* Start on touch event rotation work
* [autofix.ci] apply automated fixes
* Use ItemTransform instead.
* [autofix.ci] apply automated fixes
* Use casts to deal with integer Coords on some platforms
* Remove rotation checks
* Transform the exit event as well
* Delete check_rotation pass
* Do casts around transform_point to handle i32 Coords
* Remove errors from rotation syntax test
* Basic event rotation test
Working changes
* Fix clicks on rotated objects
* Add RendererSealed::suppports_transformation for runtime checks
* [autofix.ci] apply automated fixes
* Add a few missing line breaks, only transform events if supported by
renderer
* Improve test
* Remove extra whitespace
* Get absolute-position working
* Ensure map_to_window does the coordinate cast thing.
* Manually test mouse-x and mouse-y, test absolute_position()
* Whitespace stuff again
---------
Co-authored-by: autofix-ci[bot] <114827586+autofix-ci[bot]@users.noreply.github.com>
The definition of an Easing namespace allows to name an easing curve
outside an expression of type easing like, for instance, a struct field.
Closes#3943.
ChangeLog: Added an `Easing` namespace to reference easing curve outside of `easing` properties.
After commit ef2e6491cd we end up processing Paths multiple times, and thus we might end up attempting to replace an elements binding. Don't do that if no new elements are declared, but yield an error if attempting to do so. We could support this in the future (appending), but for now it's better to produce an error.
Fixes#9170
The padding property is accepted but doesn't have an effect.
It was meant for future use but didn't get any use.
And people get confuse when they set it. (See #8829)
Closes: #8829Closes: #6288
Technically a breaking change, although code generation was very likely
to panic.
Fixes#8743
ChangeLog: Enums without value cause compilation errors (instead of panics)
This fixes the contents of the `n`-th repeater inside the
`ComponentContainer` to also show up in the `n`-th repeater *after*
the `ComponentContainer`.
The ComponentContainer is lowered to a Comonent Container and a
dynamic tree node. The tree node is managed manually and I messed
up the repeater indices since there were no entries in the repeater
array for the embedded components. That mad things hard to keep
consistent as components get merged.
This chnages that: It lowers a Component Container to Something like this:
```slint
ComponentContainer {
if false: Emtpy {}
}
```
This way the standard mechanismns make sure we have something to put into
the repeater list and that unscrews the indices, saving a bit of code along
the way.
The inserted repeated node is still marked as `is_component_placeholder`, so
that we can wire it up as needed.
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
The Window geometry depends on its constraints, so its constraints
cannot depends on its geometry
This fixes Infinitely growing layout, and other panics
Fixes#3989Fixes#2902Fixes#8065
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.
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>
`ContextMenu` -> `ContextMenuArea`
`ContextMenu` must have a `Menu` child.
`MenuItem` can no longer be put dirrectly in `MenuBar` and can no longer
have children
`Menu` is used now for sub menus
This can only be used internally by the style to implement the actual
ContextMenu
Only the declarative `MenuItem` interface is exposed.
* [autofix.ci] apply automated fixes
---------
Co-authored-by: autofix-ci[bot] <114827586+autofix-ci[bot]@users.noreply.github.com>
Consider
```slint
// Some code in the wild actually have made their own menubar before
component MenuBar { /* ... */ }
component Row { /* ... */ }
export component Main inherits Window {
// This should find the declared component and not the builtin component
MenuBar { }
GridLayout {
Row {}
}
}
```
Previously, `MenuBar` and `Row` were first resolved against
`additional_accepted_child_types` and so it would always find the
builtin one.
But this patch changes that to find the builtin one only if it hasn't
been replaced by another component with the name name.
(So we'd use the cusom MenuBar and the custom Row)
Another change is that we also lookup the
additional_accepted_child_types if they are in a @children.
```slint
component MyGrid {
GridLayout { @children }
}
export component Main {
MyGrid {
// This used to be an error but is now accepted
Row { }
}
}
```
It said `Cannot override property 'background'` because color is defined
as below
```slint
property <color> color <=> background;
```
For the warning, the name should not be resolved.
Fixes#6324
