One More Thing - Final Prototype Released
Published on by TheFake VIP· 3 minutes readEdited on by TheFake VIP
As we announced recently, we decided that we’d learned enough from the Odilia prototype to actually implement the real thing. The prototype code, while functional, prioritised experimentation over quality, and thus we’ll be throwing almost all of it out completely, but the code is far less important than the experience we gained from writing it.
As far as I’m concerned, ditching the prototype completely was always part of the plan. From personal experience, large projects always get rewritten after a while, so I figured it would be better to plan for that, and reap the benefits of a clean, modular codebase, hopefully free of bad decisions.
Plan to throw one away; You will, anyhow.
Fred Brooks - the Mythical Man-Month
It does, however, mean we might not have another release out for a while. So we decided to glue together the latest work in the prototype, get it compiling, and release it, as a very early look at what Odilia could be in the future.
Changes Since the Last Release
Since the first prototype, almost everything has changed:
- We upgraded to the Rust 2021 edition.
- All our code will use
edition = "2021"
going forward.
- All our code will use
- After analysing our options, we decided to ditch binding libatspi using GObject Introspection, and instead
communicate with at-spi directly over D-Bus. In the prototype this has been done with the dbus
crate, but we intend to use zbus going forward.
- The community around
zbus
seems more active, and its API, workflow, and tight Tokio integration will work well for us.
- The community around
- We introduced input handling using the evdev kernel API, and used it to allow you to press
the ctrl key to pause speech.
- I plan to explain our rationale behind using evdev, instead of a higher level library like lininput, or for that matter at-spi’s own input events, in a future post, as it’s an interesting topic.
- Using evdev requires specific permissions to be set up via udev, so we created a setup-permissions.sh script to do this for you.
- We added support for different modes in the odilia-common crate, though these were never fully taken advantage of.
- We added basic, messy structural navigation.
- We made sure the screen reader can’t panic by trying to read non-existant accessibles. Instead, it will only read the attributes of the valid ones.. If an invalid accessible is incountered, it will silently be skipped for now.
- We changed all debug messages to use the fantastic log crate, with env_logger as the log
implementation.
- This means you can control Odilia’s log output with the
RUST_LOG
environment variable, see the env_logger documentation for examples of what you can set this variable to.
- This means you can control Odilia’s log output with the
Using It
If you want to try out this last prototype for yourself, you can download it from the Github release. Here’s a direct link to the compiled program and scripts.
As I said above, evdev is normally a privileged interface, since any
application that can access it could use it for malicious purposes, for
example, creating a keylogger. For this reason, to run Odilia, you must give
yourself access to evdev. This can be done by running the setup-permissions.sh
shell script included with Odilia. The script adds some
udev rules, then creates an odilia group. Any users added to this group and the
input
group will be able to run Odilia.
Once you’ve given yourself the correct permissions, you can start Odilia by
running startup.sh
in the release tar ball. You can stop Odilia by running
shutdown.sh
.
Since this is the final release, we won’t be fixing bugs, but if you have any feedback, feel free to leave it on Github.
Stay tuned, we’ll be posting about the new, production-quality Odilia soon.