Slint UI Library
We're busy preparing for Embedded World 2022 in Nuremberg from 21st to 23rd of June. Stop by at booth 4-302 if you happen to be there!
We still landed the initial accessibility work we have been working on and got a contribution improving the TextInput and TextLabels and got our Live Preview working in the browser running VSCode and GitHub webIDE.
Live Preview in VSCode WebExtension(#1330)
Start working on a preview for the web extension in a tab
Also cursor is hidden in read only mode but focus is still enabled like Qt QLineEdit and QTextEdit
Thank you to pubg-hacks for this pull request!
Basic accessibility support for Slint UIs (#1294)
This PR adds support for tools like screen readers to Slint UIs. It rebases the
slint-ui/accessibilitybranch on top of the
*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!*
This is what it does at this time (turn on sound to hear the screen reader;-):
The big picture for this PR is this:
First some new
accessibleproperties) are added to the Slint compiler so that UIs can provide the extra information needed.
Then some of the pre-defined widgets get annotated with these
Finally the information is provided to the OS accessibility support layer via Qt's accessibility code. Qt has the charm of handling the major desktop platforms. Other backend implementations can be added as needed.
What does work?
- Support for all desktop OSes via the Qt accessibility backend. Other targets are currently not supported.
Making elements accessible by assigning the
accessible-roleproperty to them. Note that you do not want to have all elements accessible as many are internal implementation details of individual widgets (== trees of elements). All widgets should be accessible of course.
accessible-descriptionto elements to describe them to the accessibility layer. These are added to our widgets where sane default values can be set.
accessibleproperties where those make sense * Implement support for reporting of values (incl. ranges) to the accessibility layer.
- Report locations of all accessible widgets to the accessibility layer
- Signalling of changes to the accessibility framework.
- Works on Rust/C++ and interpreter.
What is missing?
- Accessible actions are not yet implemented, so right now this is limited to normal keyboard focus/shortcut actions.
- Not all widgets we have are covered yet. Most notable is the text edit. There is no support for the edit actions, so this seemed of somewhat limited use at this time.
- Relations between objects are not generated yet.
- We do not report the full state of widgets yet.
What should be done next?
Improve the widgets to be more keyboard friendly and to add
accessibleproperties where that makes sense.
- Implement different back-ends so that we do not have to rely on the presence of Qt.
The most critical missing piece is of course that testing by real users is missing! This will most likely have some glaring problems I did not notice while testing as a seeing person.
As usual: Feedback is very welcome in all possible forms.
Fix panic about multiple mutable borrows with the software renderer (#1329)
When using repeaters - like in the slide puzzle - and during renderer a component gets deleted, we call
free_graphics_resourcesand try to free the dirty rectangle list in the partial renderer cache. At that point the cache is already mutably borrowed, which causes a panic.
As remedy, apply the mutable borrow more fine grained and not right when calling render().
83 patches were committed in 5 pull requests by 4 authors.