edit3:
changed topic title, to reflect the current name of the project
edit2:
the yggdrasil screenreader is no longer called yggdrasil, due to several factors, we decided to call it odilia. So, everything just moved ship to the new organisation, as well as a new domain for the project. All the links will be updated to reflect this change.
end edit2
edit:
I changed the topic title, since we have something to show now
end of edit, original post from here on
Hello there!
for anyone who didn't see this topic, I am deeply passionate about linux and its ecosystem, its philosophi, flexibility due to modular design in the kernel and so on. It has many great things, including a good ecosystem for developers, a friendly community **most of the time**, a reputation of being able to run mostly anywhere including low spec computers and even embedded systems, light desktop environments and a great choice of such, swapable components and great customisability, but what it doesn't have is proper accessibility, well, proper for 2021 days, not for msaa days.
Maybe that's so because of orca and it's slawppy design, maybe it's also so because sun, the makers of solaris, fired most of their workers on accessibility, and therefore accessibility on linux desktop became a community effort ever since, don't know exactly and honestly I don't care as much about the past as about improving the future. I learned from the past of orca, of at-spi, of the design of solaris, now I hope things will be better, so it's worthless to investigate further into this I think.
In that spirit, I'm attempting to make a screen reader for linux that brings, as much as possible, the features windows or mac OS screen reader users expect to have in linux as well, it's time for linux to catch up to its competition, I no longer want to hear linux is inaccessible, I must use windows or mac OS, orca freezes in linux, therefore windows comes to the rescue, linux is slow, therefore windows, orca consumes too much memory, therefore windows ftw.
The screen reader will be made in rust because I want it to consume as less memory and cpu resources as possible, I want system call latency to be minimised, but at the same time, I want to make great use of the hardware the sr is running on, for example, don't throtle one cpu core with all of the screen reader if given the option, use async more often, it can't hurt and so on. With all that in mind, a compiled language will be most appropriate for this task. Sorry python, you've been used long enough.
Only a year ago, I would have chosen c++, afew months earlier I could have chosen go, but probably not anyways, goroutines, the gc and error handling would have been the cause for regection.
Then, by learning more and more of rust and how it works, I really begun to see its advantages and how it mitigates security vulnerabilities due to memory bugs like double free errors, buffer overflows, writing to or reading from unallocated memory...I could go on for a long time. So yeah, that would probably mean my sr would be safe to some degree, safer than a c or cpp implementation.
for those people who say I should build this in c++, I am hearing your arguments, never could dream otherwise. However, I give you this, preemptively. The blog has a lot of images with code, out of which I am trying to extract the text, but it's not working so well. However, there are valid points in there, even without the images, try to make an abstraction of them. DK why they chose images in stead of straight out write code in the post, but yeah, weirdness I guess.
the philosophi behind this is that yggdrasil will provide what orca never could, at first only within the bounds of at-spi limitations, then probably with fixing issues upstream, like touchscreen support.
What we plan to implement and a vague idea of how is written in the design document of the screen reader, on its site, inside its github org.
additional links
the root of odilia project, the github org
the website of odilia
a rough draft of the odilia design documentation