lukexor
AccessKit can result in a thread sleep deadlock
When adding AccessKit support, it was discovered that (at least on linux) that the accesskit implementation puts the thread to sleep and never wakes up. This happens in side async-io waiting on a zbus response inside a block_on request.
Need to gather more data for submitting an issue upstream and test on other platforms.
macos does not seem to have this issue
Hello @lukexor, thanks for trying out AccessKit.
The issue you describe here might be linked to the fact that the version of accesskit_unix used by egui doesn't implement lazy initialization, which might cause troubles if you are not running any assistive technologies on your system.
I can help investigate this once egui updates the dependency.
CC https://github.com/emilk/egui/pull/4702
Hello @lukexor, thanks for trying out AccessKit.
The issue you describe here might be linked to the fact that the version of accesskit_unix used by egui doesn't implement lazy initialization, which might cause troubles if you are not running any assistive technologies on your system.
I can help investigate this once egui updates the dependency.
Thanks for the info! I'm actually working on a change to remove the egui winit and wgpu dependencies so that I can update those dependencies, which will mean implementing the access kit integration manually so I should be able to implement the required fixes as soon as that works completes
I'll also add that it worked fine when the builtin screen reader in popOS was disabled and would read menu items as expected when it was enabled.
However, randomly but consistently when opening a menu or trying to interact with the UI besides just tabbing through widgets, the main thread would go to sleep and never wake up, freezing the main thread requiring it be killed.
accesskit is updated now, still a version behind but this can be tested again