well, I thought of this for some time, and DK if it'd really be useful to split development between making the screen reader as well as adding every message string to the translation bucket, it'd just throttle the development further. However, if the project becomes successful and actually a reality, we will surely implement it. I added it on the metaforical discussion board just now, in case it interests someone. I am always open to feedback, keep the features coming. When most of the bindings will be done and it's time to make a rough prototype, a.k.a an alpha release, then will be bug tracking time, feel free to open issues or whatever.

Time will tell. It is easy to speak about great deeds, but its billion times harder to actually make them, and I know that from experience. SO with cautious optimism I wish you the best of luck.

IMO it's way too early for this type of topic to exist. I mean it's a screen reader, is anyone gonna be like, "I hate this idea, you should jump in a pit of hot tar!"

hello there, community!
so, I'm very happy to bring you the first release of yggdrasil, after a long, long silence, we finally have something to show.
Warning: While I said a release has been made, this is very alpha software, plus it's a prototype that is going to be scrapped in afew iterations. If it makes more sense this way, it's more of a proof of concept, a demo of sorts. Once we see this thing can be done, we'll either yank the prototype repository or mark it as archive, it's not decided yet.
What can it do yet? well, none of the features we were hoping for, but at least it's working as we expected.
What it can do though is read the elements on the screen, like orca or any other screen reader on any other platform can. It has some known issues and limitations, I posted them on the website of yggdrasil, under the news level 3 heading. I will update the first post with the yggdrasil info, including website and so on
If you don't want to go through all that, here's the link for the release
https://github.com/yggdrasil-sr/yggdras … /releases/
expand the assets menu, click on the file with the .run extenssion. I put it there with a .run extension just because it should be easily recognisable and distinguishible from the zip and tarball of the source code, for whatever reason that's there, don't we have clone/download zip options on the github website?
anyway, back from my rant, download that, make it executable if it's not already, then run it. Have fun, and don't forget to open issues in case you incounter bugs. Yes, this might be a prototype, however even though the code will be removed, the lessons we learn from it will not be as lost, we will make the true release with those fixes in mind from the start.
Btw, for who is curious about the code, yes, I know it's not the best, or cleannest, or the most idiomatic to rust, however I wanted to get something going, and get it going as soon as possible, squashing as many bugs as I discovered and knew how to fix. For more info about those I couldn't, look at the known issues paragraph on the website.
replyes, suggestions, even better, contributions? post them here, open issues, pull requests, you name it, I will reply as soon as possible.

@10 we don't use those because they either don't exist or don't have what we need or are coupled with other systems, or maybe only implement the interfaces apps use to expose accessible controlls and so on, not the API's required for screen readers. Whichever the case, we definitely looked into those possibilities and some of the above happened. Either ways, because of the binding generator not generating getter fields for structs and us having to implement it by hand and many more things like those, we are experimenting with not relying on libatspi at all, only using the dbus specifications that come with the package and the dbus crate to make our own wrappers, in this way there could be only very small amounts of unsafe in our code, as well as we probably gain afew cpu cycles, as the rust><glib translations and data passing has a cost that could probably be minimised even more. For example, because of glib's oop like constructs, we have to make a lot of weird artefacts to get the two parties to behave, especially over ffi. Ever tryed wrapping a garray, I sure hope you don't have to. I'm more than sure such stuff is not harder than an OS kernel, but there are just so much unsafe you are gonna allow in your code before going riir and be done with it. Currently, we made a thing that coppies the elements into a vec and so on, so life without glib for a little longer won't hurt anyone. Another benefit to using dbus directly would be that we can integrate tokio and all its goodness with dbus, so we can have the best of both worlds, while glib only has its own executor and something that interfaces with async rust, but still doesn't use and can't be used with tokio.
We have been discussing that for afew days, we either do that, make a C wrapper with a friendlier API without the weirdness of glib so it can better be used by rust, or, DK, write the whole sr in c++...nah, just kidding with the last one lol.
about your code observations, yes, it surely is a prototype, I did whatever it took for it to compile and work as I expected it to. That last unwrap there, woops, I honestly forgot, weird clippy didn't give me any warnings, or is vscode weird again?
and about me renaming the repo, DK, even if that were to happen, all the code would be scrapped anyways, refactoring it so that it would meet our designs would not be worth it at this point.

hello there, again!
I'm glad to write in this thread again, with very interesting news indeed!
So, first of all, yggdrasil is now on google, yes, you're right, a google search for yggdrasil screenreader will find the main website of the project, yes yes, the moment finally came!
Another thing is that yggdrasil is now on hacker news as well. DK who posted it there, though I assure you, it was none of the organisation members or the ones in the discord server, it was a total stranger to the project, thinking it has potential or something, hell if I know. This is what I think is the true joy of a project maker, to see their projects out there, enjoying a bit of popularity...kinda. What's even better is when this happens without too much intervention from the creators, when the project is inspiring in its own, making unrelated people promote it just because of that, not because they might need the product.
One more thing, because we decided we're going to ditch libatspi entirely and are now rebuilding the mechanisms only in dbus land, the next prototype release will probably be delayed more, since technical reasons and frustration made us incapable of continuing anything with the existing C library bindings.
All that considered however, I think yggdrasil is picking up steam really fast, hope it will be in a better state soon because of that.
btw, @ethin, I'm about to send you a pm, if you're interested in yggdrasil.

well, you actually will be able to soon, with enough features to get by, though it might not be the best experience yet. With the actual prototype, you will indeed be able to run most normal gui apps, however you can't use edit boxes, terminals and webviews yet. The next iteration is fast approaching, we're still experimenting working with the raw dbus interface and producing something that can be used. This release might be delayed more than expected, however it'll have new features compared to the prototype, features that orca possibly doesn't have.

I like the first prototype a lot! I've never witnessed a screen reader work at a constant fast speed before in my many years of using computers. I do, however, feel strongly compelled to make a suggestion which I personally feel is important.
BGT Lover. I seriously admire your creativity when you came up with the name of the screen reader. I can't remember the exact origin of the name, but I do remember it being clever. All the same, I feel that for the screen reader itself, this isn't the best name to go with. I struggle to even spell Yggdrasil let alone pronounce it, and I'm sure there's many people who might feel the same. Sometimes simple is the way to go when it comes to people using a product. Some who hear the name might think "Oh, based off the name it already sounds complicated to use."
My initial suggestion before this screen reader had a name was Blab. It makes sense because screen readers read everything on the screen, so they talk a lot, or blab. Short, simple, and to the point, just as all things should be.
Keep in mind, I'm not suggesting you ditch Yggdrasil entirely. It could make an amazing name for your organization. I'm simply suggesting that in terms of a screen reader name, it just screams needlessly complicated to me.
Just take this as a suggestion though. At the end of the day, it's your project, not mine. I'm simply giving my input on how you can improve your product.

@17
[Yggdrasil] is a mythical world tree in Norse mythology, though I think referring to it as an abbreviation of "Ygg" in conversation could probably suffice.

As for the wish bucket of features in some hypothetical future, how about support for [IPA Braille] and advanced mathematics symbols? As I understand it most screen readers struggle with the stuff, although Jaws has a few supplemental scripts around for it.

@20, I don't think it would be a bad idea, however I would still recommend you hold off doing it for now, we don't have enough to show yet. The publicity that we encountered is welcome, but nevertheless not our doing, we won't have done it so early. If you want however, sure, you can post in there, but with the mention that the code we have so far in the prototype repository is horible by rust standards exactly because it's a prototype and that it won't be like this in the non-prototype versions, you can refer them to the design documentation for a clearer picture of the true way we expect the code to be in the end.
@19 and 17, we in the community still refer to it as yggdrasil, however most utilities and things would be indeed prefixed by yg, for example ygs would be the yggdrasil settings program. So yeah, programs can and do change names from time to time, we are open to doing so if we see an actual benefit to it, however not for now. That name is a symbol for all we stand for, accessibility unifying people across the world, across platforms, across devices even, allowing collaboration greatter than anything done before through making the avenew of linux desktop accessible to the visually impaired, increasing productivity levels untill they are on equal footing with windows and Apple Mac OS. This will be hard to achieve for sure, it will surely require more than yggdrasil, for example modernising of the accessibility stack because there will be just so much we can push the boundaries of the current technology, it will also require efforts to be made across multiple parts of the ecosystem, for example wayland and possibly adding privilidged status to user authorised accessibility services or simply making the compositor talk more directly to atspi, etc. What I know however, this name, this symbol, is the meanning around which our vision centers itself, it's an integral part of the modernising of linux accessibility effort now, we can't change it so easily.
about braille, no, not in the prototype, we're gonna ditch this codebase soon enough, around two more releases and we're done with prototypes. We'll do whatever we can, possibly borrowing some nvda source regarding braille if you think nvda performs well enough with it. I'm not a braille user my self, no one on our team is for now. I always used speech, I didn't know braille displayes existed untill 2018 or so, so pretty late in my computing career to matter, maybe this is also because I was mainstreamed after I finished primary school, dk. Once braille support comes out, we would need testers with braille displayes and such things, people who know how to use that side of the spectrum profficiently. Then, perhaps it's where you come in.
@16, I sent you a pm replying to the previous issue, I recommend you check it out before it, too, expires.

Agreed. "Blab" is just... childish.