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>
Technically a breaking change, although code generation was very likely
to panic.
Fixes#8743
ChangeLog: Enums without value cause compilation errors (instead of panics)
* 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
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
eg, don't report an error for each callback or animation or changed
event that the the property doesn't exist or such.
Also reword the message when an element doesn't exist. Use "element"
rather than "type" as it is more accurate.
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"
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
* 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 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
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)