Currently it's always the second, but that's not great.
Ideally it should be the current active element, but that's hard to
compute
This becomes extra-relevent when our preview UI has a combobox on the
top and that it is clipped to the window by winit
Fixes https://github.com/slint-ui/slint/issues/3345
* 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
* Optimize StandardTableView in Fluent and Material styles
By using a ListView instead of a ScrollView + VerticalLayout, we trigger
the optimization where only visible children are being instantiated.
For the Fluent style, this was making the rows more compact, so I've
added additional padding to the TableViewCell to compensate. I don't
know where the padding used to come from.
I didn't touch Cupertino style since it's currently work-in-progress.
This optimization can be done there as well.
For the Native style, this optimization isn't as straight-forward
because it uses a NativeScrollView + Flickable directly rather than a
the ScrollView.
* Optimize StandardTableView for Native style
Using the ListView makes it possible to only instantiate the visible
items, which makes the StandardTableView a lot faster for larger models
(already very noticeably in the gallery example).
When using a ListView, StandardTableView lost access to the
NativeScrollView.native-padding-top/left properties, which are now
exposed through the ScrollView item.
It could also no longer position the Flickable below the header (or in
doing so, would take the scrollbar along with it), so a property was
added to ScrollView for that purpose as well.
* Introduced InternalScrollView
This avoids exposing additional properties on the ScrollView for just
the native style.
* Fix missing default values for Native style ScrollView
Added minimum size, preferred size and stretch factors (they were not
present before introducing InternalScrollView either, but are added now
for consistency with the other styles).
* Refactor ProgressIndicator api according to api review.
* Update docs/language/src/builtins/widgets.md
Co-authored-by: Simon Hausmann <simon.hausmann@slint-ui.com>
* Capping progress also for native.
---------
Co-authored-by: Simon Hausmann <simon.hausmann@slint-ui.com>
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.