When having a binding such as
```
foo <=> bar
```
The default value will always be the value of `bar` regardless what's
the value of foo.
This change of behavior is the only one that makes sense bacause if we
are having repeater or if, this will be a problem. eg:
```
property <xxx> bar;
if (some_cndition) : SomeElement {
foo <=> bar;
}
```
Then we can't possibly take the default value of foo for the value of
bar since it depends on the condition. (and it is even worse in case of
repeater)
This is a change of behevior, this is why the tests have changed. The
cse of tests/cases/bindings/* were already covered by a warning since
0.3.0 so that should be fine. But the warning did not trigger for
builtin property such as `visible` (eg, input/visible_mouse test)
Also some internal two way bindings had to be reversed.
cc: #1394
Permit the style metrics to provide a `default-font-size` and bind that
to the `Window` if set. If not provided, then the backend can set a
`default-font-size`. By ensuring that the value is non-zero at run-time,
we can later introduce a rem unit that can act as factor relative to
this non-zero font size.
These are two different concept, and it is confusing to keep them in the
same enum
We want to support component without any base element, and Void is
already used for global component, so do this refactoring before
This allows setting the RUST_FONTCONFIG_DLOPEN environment variable
to dlopen fontconfig at runtime rather than linking it at build
time. This is helpful for cross compiling to Linux, particularly
because fontconfig has lots of C dependencies. Building a vendored
copy of fontconfig does not work as expected:
https://github.com/slint-ui/slint/issues/88
in the funciton `visit_layout_items_dependencies` we were passing a
NamedReference for a property that could have been in the base
component type of an element, instead of in one of the element within
the current visited component. This would result in wrong computation
done later to find out the "element path" of the property.
We then need to tell the visitor that the named reference is in a sub
component. To do that, we need to visit a PropertyPath instead of just a
NamedReference
Issue 1659 was showing one of the symptoms of this, which was an assert.
But it could also result in wrong analysis (binding loop not detected
when it should or vice versa)
Fixes#1659
Some binding can't be express with the current data structures because
they reference propertis within inner elements within a component.
The fix is a bit involved and the best is to have an error istead of a
panic, for now.
The rotation-angle/rotation-origin-x/y properties are lowered to an
injected Rotate element, that we already had.
This needs further fixes for transforming input events and an
implementation of rotation in Skia.
This is the most basic loop and we wouldn't show a signal.
Turn out the comment was wrong and we do not seem to emit the error
twice for two ways binding to itself
Fixes#1407
Because of issue #1394 and because the semantic are not properly defined
currently, we decided that future version of slint should always and only
take the binding from the right hand side, even if it has no bindings.
Since we can't change the behavior in 0.2, just add a warning instead for now.
The warning can be silenced by setting a default binding for the property on the rhs.
Ignoring the warning can still lead to panic (the one in #1394)
state info properties are special and cannot simply be inlined or set
(because we need to record the time it was changed and stuff)
So disable the optimization for now.
In fact, what could be done is to remove the state entirely if the state property
is constant. But that change is a bit more involved
This patch does:
- Don't inline const state property
- Don't generate a call to .set in the generated code
- Also allowed to debug the expression with a context from the generator
(added T generic parameter to the pretty printer)
Fix panic reported in https://github.com/slint-ui/slint/issues/1327#issuecomment-1151244049
Implement some very rudimentary font fallback handling and add some the
glyphs the puzzle needs.
The font fallback handling deserves to go into a module shared between
GL backend and the compiler.
For the character selection we should scan the text elements for
literals just like we do for the font size.
Make sure to embed whatever we pick as default font, but also register
any custom imported fonts.
This fixes the plaster font not showing up in the slide puzzle on the
stm32.
Implement basic accessibility (a11y) support, using the Qt backend.
_This should get us started, but accessibility support is an additional way to interact with UIs that is very different from the "graphical way" most users will interact with the UI. No single PR will "make a toolkit accessibility", this needs to be an ongoing effort!_
Parts of this PR:
* Add functions to access a11y-related properties to Component
* Add helper functions to Item struct
* Handle accessible- properties in the compiler
* Add documentation, add description, enforce some basic rules
* Make the Text element accessible by default
* Don't optimize away accessibility property in the LLR
* Ensure that accessibility property are marked as used
* Add some accessibility properties to the native style widgets
* Support for bool and integer `accessible` properties
* Implement basic support for accessibility
* Make basic widgets accessible by default
* Make slider focus-able and interactable with keyboard
* Tell a11y layer about value changes
* Generate QAccessible constants using bindgen
* Don't expose the `accessible` properties when using the MCU backend: There is no backend to make use of them
* Handle focus change based on keyboard focus of the window
* Report accessible widgets at correct positions
* Allow for (virtual) focus delegation at the a11y level
* Calculate value step size dynamically
* Make sure to not send notifications to a11y backend about dead objects
We can't use file system call to load files with wasm, we need to go through the vscode API
Note that this is all async, so i had to prevent re-entry within the compiler using a rentry trick.
I removed the lifetime in the TypeLoader because I thought this was going to be necessary
to get 'static futures. But it turned out not to be necessary. Anyway, I kept it htis way because
it is actually nicer IMHO, even if the CompilationConfiguration is now copied
When the percentage is missing, we should interpolate between the
last valid entry to the first valid entry after that, not always the
last valid entry in the whole gradient
The `lower_property_to_element` pass usually disallows that because it
injects the Layer element and we can't do that for components. But we
can handle this like with opacity and inline.
Normally, child of layout don't get optimized anyway because
the layout sets their `x` and `y` prop, preventing the optimization.
But if the rectangle has an opacity, its `x` and `y` property are
stolen by the opacity element, and then it can get optimized anyway
Fixes#1267
This avoid repeating the enums both in the compiler and in
the runtime library, and register them in a bunch of other places.
So it should be easier to add enums and enum values
Since cbindgen doesn't see through the macro, generate the enum
manually
Continue to support specififying logical font sizes in the compile step
via SLINT_FONT_SIZES, but additionally look for Text/TextInput/Window elements
and extract any constant font sizes
found.
This makes it work out of the box with the printer demo.
* Make sure that the compiler don't panic if the parent of a PopupWindow
is optimized (by not optiizing such element)
* Ensure that we can call popup.show() from within a deeper repeater
* Ensure that the parent element of the popup is the right one in case of
repeater (and not the node in the parent component)
This partially revert ad5991f8fa and
6c7a7aed0e because we must do the lower_popup
adter the repeater pass, because otherwise the parent element of the
created component for the PopupWindow might be wrong and it is not easy to
adjust (we would have to make Component::parent_element a RefCell or duplicate
it again.
Fixes#1132
* The LLR expect that the popup_window is actually contained in it's parent
component popup_windows, otherwise the context is not correct.
* There is no index property for a PopupWindow
Fixes#1113
