And call `extern crate std` when the feature is enabled.
I've read this is the good practice on how to do it.
So that the std prelude is no longer included automatically.
There is then less difference between std and and no-std build which
should avoid surprises in the CI when we use things from the prelude.
The downside is that there is a bit of churn in the tests
Based on API review, PlatformBuilder becomes BackendSelector with
a slightly smaller API surface but more options, such as selecting
Metal or Vulkan rendering.
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"
and their related name.
Also move the component module in the item_Tree module
register_component -> register_item_tree
ComponentItemTree -> ItemTreeNodeArray
For #3323
Rationale from that issue:
Right now, we use the term `component` in the Slint language and in the compiler to be a a tree of elements that can be used as an element in a .slint file.
The term is also currently used in the runtime as a tree of runtime Items that are allocated together. (declared in ComponentVTable)
But there are no 1 to 1 mapping between a `component` in the slint language, and a runtime Component.
(for example, the items behind a `if` or `for` or `PopupMenu` are in a different runtime component. And `component` declared in Slint are often inlined)
So we should rename the internal runtime `Component` to `ItemTree`
The currently public `slint::ComponentHandle` wraps the "root" of the ItemTree, but that's ok because it is generated from a .slint `component`, so it doesn't change name
Add a ComponentFactory type which will eventually be used as a property
value in Slint. The idea is to copy around this type and to create
components from it that we can embed.
We do not want to hand raw components around as those are reference counted
and might end up being embedded into several places, which would break out
tree of components.
This doesn't seem to be needed anymore with newer rust version.
As long as one symbol from the crate is used, all exported function
from the crate are available.
The reason why some symbols in some module were gone was a bug in rust
that has been fixed, it seems
I missed some instances as the CI and @ogoffart both pointed out. Fix
that.
Also make the `text_layout`and `ìnteger-sqrt` features that were set by
the `swrenderer` feature mandatory -- by removing them completely.
I want to track component structure changes in the window without
generating more code. So use a more generic name for the init_*_items
functions, so that I can add the functionality I need in there.
Also add a register_component to PlatformWindow and call that.
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
The flickable module was created to hold the implementation for the Flickable
at a time were all the items lived in the items.rs module.
Now that some items moved into sub modules of items, we can also move the Flickable
in such module, alongside its implementation
