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
- Rename `accessible-selectable` and `accessible-selected` to `accessible-item-{selectable,selected}`.
Because the property is for items in list rather than eg Text
- Rename `accessible-position-in-set` to `accessible-item-index`.
- Rename `accessible-size-of-set` to `accessible-item-count` and move
the property to the container element rather than the item itself
Because we don't support it in Qt and in our widgets yet.
Also accessible-action-set-value now takes a string because value is a
string (for the line edit)
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"
With just the Qt accessibility support, this is not impactful.
But with accesskit it'll be useful to avoid the intermediate vector of ItemRcs
and map directly to a different data structure.
Otherwise, this is a trade-off between the stack allocation of the recursion and
instead allocating the stack of pending itemrs
on the heap.
Add flags that enable the Button to be used as a Toggle, e.g. for use in toolbars or similar places.
Co-authored-by: Simon Hausmann <hausmann@gmail.com>
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
