[Merged by Bors] - Integrate AccessKit

[ndarilek]

Objective

UIs created for Bevy cannot currently be made accessible. This PR aims to address that.

Solution

Integrate AccessKit as a dependency, adding accessibility support to existing bevy_ui widgets.

Changelog

Added

• Integrate with and expose AccessKit for platform accessibility.
• Add Label for marking text specifically as a label for UI controls.

[james7132]

Does this need to be NonSend? This is going to run up against #6552 eventually. If we can make it Send, it'd be for the best long term.

[ndarilek]

Here are the errors I get when trying to drop the NonSend requirement. Not sure if there's anything I can do about them, but please let me know if there's some other way of storing this:

error[E0277]: std::cell::Cell<bool> cannot be shared between threads safely
--> crates\bevy_winit\src\accessibility.rs:28:10
|
28 | #[derive(Resource, Default, Deref, DerefMut)]
| ^^^^^^^^ std::cell::Cell<bool> cannot be shared between threads safely
|
= help: within accesskit_windows::subclass::SubclassImpl, the trait Sync is not implemented for std::cell::Cell<bool>
= note: required because it appears within the type accesskit_windows::subclass::SubclassImpl
= note: required for Unique<accesskit_windows::subclass::SubclassImpl> to implement Sync
= note: required because it appears within the type Box<accesskit_windows::subclass::SubclassImpl>
= note: required because it appears within the type accesskit_windows::subclass::SubclassingAdapter
= note: required because it appears within the type accesskit_winit::platform_impl::platform::Adapter
= note: required because it appears within the type Adapter
= note: required because it appears within the type (bevy_window::WindowId, Adapter)
= note: required for RawTable<(bevy_window::WindowId, Adapter)> to implement Sync
= note: required because it appears within the type bevy_utils::hashbrown::HashMap<bevy_window::WindowId, Adapter>
note: required because it appears within the type Adapters
--> crates\bevy_winit\src\accessibility.rs:29:12
|
29 | pub struct Adapters(pub HashMap<WindowId, Adapter>);
| ^^^^^^^^
= help: see issue #48214
= note: this error originates in the derive macro Resource (in Nightly builds, run with -Z macro-backtrace for more info)

error[E0277]: std::cell::Cell<Option<Box<(dyn FnOnce() -> accesskit_windows::adapter::Adapter + 'static)>>> cannot be shared between threads safely
--> crates\bevy_winit\src\accessibility.rs:28:10
|
28 | #[derive(Resource, Default, Deref, DerefMut)]
| ^^^^^^^^ std::cell::Cell<Option<Box<(dyn FnOnce() -> accesskit_windows::adapter::Adapter + 'static)>>> cannot be shared between threads safely
|
= help: within accesskit_windows::subclass::SubclassImpl, the trait Sync is not implemented for std::cell::Cell<Option<Box<(dyn FnOnce() -> accesskit_windows::adapter::Adapter + 'static)>>>
= note: required because it appears within the type once_cell::unsync::Lazy<accesskit_windows::adapter::Adapter, Box<(dyn FnOnce() -> accesskit_windows::adapter::Adapter + 'static)>>
= note: required because it appears within the type accesskit_windows::subclass::SubclassImpl
= note: required for Unique<accesskit_windows::subclass::SubclassImpl> to implement Sync
= note: required because it appears within the type Box<accesskit_windows::subclass::SubclassImpl>
= note: required because it appears within the type accesskit_windows::subclass::SubclassingAdapter
= note: required because it appears within the type accesskit_winit::platform_impl::platform::Adapter
= note: required because it appears within the type Adapter
= note: required because it appears within the type (bevy_window::WindowId, Adapter)
= note: required for RawTable<(bevy_window::WindowId, Adapter)> to implement Sync
= note: required because it appears within the type bevy_utils::hashbrown::HashMap<bevy_window::WindowId, Adapter>
note: required because it appears within the type Adapters
--> crates\bevy_winit\src\accessibility.rs:29:12
|
29 | pub struct Adapters(pub HashMap<WindowId, Adapter>);
| ^^^^^^^^
= help: see issue #48214
= note: this error originates in the derive macro Resource (in Nightly builds, run with -Z macro-backtrace for more info)

error[E0277]: UnsafeCell<Option<accesskit_windows::adapter::Adapter>> cannot be shared between threads safely
--> crates\bevy_winit\src\accessibility.rs:28:10
|
28 | #[derive(Resource, Default, Deref, DerefMut)]
| ^^^^^^^^ UnsafeCell<Option<accesskit_windows::adapter::Adapter>> cannot be shared between threads safely
|
= help: within accesskit_windows::subclass::SubclassImpl, the trait Sync is not implemented for UnsafeCell<Option<accesskit_windows::adapter::Adapter>>
= note: required because it appears within the type once_cell::unsync::OnceCell<accesskit_windows::adapter::Adapter>
= note: required because it appears within the type once_cell::unsync::Lazy<accesskit_windows::adapter::Adapter, Box<(dyn FnOnce() -> accesskit_windows::adapter::Adapter + 'static)>>
= note: required because it appears within the type accesskit_windows::subclass::SubclassImpl
= note: required for Unique<accesskit_windows::subclass::SubclassImpl> to implement Sync
= note: required because it appears within the type Box<accesskit_windows::subclass::SubclassImpl>
= note: required because it appears within the type accesskit_windows::subclass::SubclassingAdapter
= note: required because it appears within the type accesskit_winit::platform_impl::platform::Adapter
= note: required because it appears within the type Adapter
= note: required because it appears within the type (bevy_window::WindowId, Adapter)
= note: required for RawTable<(bevy_window::WindowId, Adapter)> to implement Sync
= note: required because it appears within the type bevy_utils::hashbrown::HashMap<bevy_window::WindowId, Adapter>
note: required because it appears within the type Adapters
--> crates\bevy_winit\src\accessibility.rs:29:12
|
29 | pub struct Adapters(pub HashMap<WindowId, Adapter>);
| ^^^^^^^^
= help: see issue #48214
= note: this error originates in the derive macro Resource (in Nightly builds, run with -Z macro-backtrace for more info)

error[E0277]: (dyn FnOnce() -> accesskit_windows::adapter::Adapter + 'static) cannot be sent between threads safely
--> crates\bevy_winit\src\accessibility.rs:28:10
|
28 | #[derive(Resource, Default, Deref, DerefMut)]
| ^^^^^^^^ (dyn FnOnce() -> accesskit_windows::adapter::Adapter + 'static) cannot be sent between threads safely
|
= help: the trait Send is not implemented for (dyn FnOnce() -> accesskit_windows::adapter::Adapter + 'static)
= note: required for Unique<(dyn FnOnce() -> accesskit_windows::adapter::Adapter + 'static)> to implement Send
= note: required because it appears within the type Box<(dyn FnOnce() -> accesskit_windows::adapter::Adapter + 'static)>
= note: required because it appears within the type Option<Box<(dyn FnOnce() -> accesskit_windows::adapter::Adapter + 'static)>>
= note: required for std::cell::Cell<Option<Box<(dyn FnOnce() -> accesskit_windows::adapter::Adapter + 'static)>>> to implement Send
= note: required because it appears within the type once_cell::unsync::Lazy<accesskit_windows::adapter::Adapter, Box<(dyn FnOnce() -> accesskit_windows::adapter::Adapter + 'static)>>
= note: required because it appears within the type accesskit_windows::subclass::SubclassImpl
= note: required for Unique<accesskit_windows::subclass::SubclassImpl> to implement Send
= note: required because it appears within the type Box<accesskit_windows::subclass::SubclassImpl>
= note: required because it appears within the type accesskit_windows::subclass::SubclassingAdapter
= note: required because it appears within the type accesskit_winit::platform_impl::platform::Adapter
= note: required because it appears within the type Adapter
= note: required because it appears within the type (bevy_window::WindowId, Adapter)
= note: required for RawTable<(bevy_window::WindowId, Adapter)> to implement Send
= note: required because it appears within the type bevy_utils::hashbrown::HashMap<bevy_window::WindowId, Adapter>
note: required because it appears within the type Adapters
--> crates\bevy_winit\src\accessibility.rs:29:12
|
29 | pub struct Adapters(pub HashMap<WindowId, Adapter>);
| ^^^^^^^^
= help: see issue #48214
= note: this error originates in the derive macro Resource (in Nightly builds, run with -Z macro-backtrace for more info)

[mwcampbell]

It's a known limitation that the AccessKit adapters don't implement Send, and one that I don't plan on changing in the near future. For me, the question is whether arbitrary Bevy systems, like the ones in the Bevy UI accessibility plugin, really need to access the adapter. Maybe the solution is to add one or more additional commands, like the one that the Bevy UI accessibility plugin already uses to add or update AccessKit nodes.

[bzm3r]

@ndarilek this is awesome!

The accesskit dependency is currently re-exported from bevy_winit. This seems cleaner than adding it as a dependency in several places. It also ensures that any plugins that implement UIs always use the version of AccessKit appropriate to the Bevy engine version. If there's a better way or if this was the wrong call, please do let me know.

I do think that we shouldn't use bevy_winit to pull in accesskit, see: #6874 (comment)

[ndarilek]

I've introduced a bevy_a11y crate for the AccessKit dependency and non-Winit code, decoupled bevy_ui from bevy_winit, and tried to clean up focus-handling so AccessKit always gets a focus as needed. I've also given the Adapters/Handlers structs less generic names to indicate their use in AccessKit.

The integration now aggressively pushes all changes to AccessKit each frame. I removed change-detection just to get something working, but this is preliminary to making AccessKit lazily poll for changes so it's only temporary.

I'd like to get action handling work next, so access technologies can tell bevy_ui to focus/click widgets. I think I'm miscalculating widget bounding boxes, and would appreciate any help fixing that. I believe Narrator has a tool to draw visual rectangles around where it thinks widgets are, but since I can't see those, I'm not sure if there's a way for me to use that tool independently. Help very welcome.

Also, there's probably additional plumbing needed to ensure bevy_a11y is more completely integrated into CI/releases. Help with that is welcome too, particularly if we can address or silence the CI warnings.

[ndarilek]

I'm removing the draft status on this, even though it isn't fully ready, because I'd like a bit more attention on it.

I don't want to go too far down the rabbit hole of modifying bevy_ui because it needs a lot of work in general, but one limitation of my current approach is that all AccessibilityNodes are treated as parents of the root window and there is no nesting. Right now the bevy_ui integration tries to generate AccessibilityNodes for widgets, but it's challenging to determine whether something like a piece of text is a label associated with a button vs. something like a standalone text label, and lots of the examples just generate and position widgets without enough context to make a usable accessibility tree. I included a Label widget/marker to get the simpler examples working but at some point we'll need to brainstorm a strategy to, say, mark some things as containers so Transform calculations are done correctly and nodes are correctly nested.

It may be that this PR has to ship with a reasonably sound AccessKit integration that others can integrate with, but a broken bevy_ui accessibility implementation, and future UI work will have to mold itself to the AccessKit integration and vice versa. But with AccessKit support in the newly-released egui, I'd really like to ship something that bevy_egui and other UI experiments can hook into. Just wanted to prepare folks for the possibility that bevy_ui may be broken for accessibility until it becomes a focus area.

[bors]

Build failed:

• check-missing-features-in-docs

[cart]

bors r+

[bors]

Pull request successfully merged into main.

Build succeeded:

• build-and-install-on-iOS
• build-android
• build (macos-latest)
• build (ubuntu-latest)
• build-wasm
• build (windows-latest)
• build-without-default-features (bevy)
• build-without-default-features (bevy_ecs)
• build-without-default-features (bevy_reflect)
• check-compiles
• check-doc
• check-missing-examples-in-docs
• check-missing-features-in-docs
• ci
• markdownlint
• msrv
• run-examples
• run-examples-on-wasm
• run-examples-on-windows-dx12

[ndarilek]

Excellent, looking forward to building on this!

Definitely cool with this as an initial step, but I think its very important to resolve this in the near future.

Agreed. I'd like to suggest that we adopt a subset of AccessKit's schema into Bevy's UI component structs, using it as the basis for our widget source of truth where possible. Essentially, the closer bevy_ui can come to creating NodeBuilders from its components, the fewer explicit accessibility examples we'll need, I feel like the accessibility schema covers much of what you'd need for a UI definition. At the very least, it'd be a solid start.

Thanks again for merging this.

[zeenix]

Most of the dependencies that AccessKit introduces on Linux come through zbus. I see three possible options for shrinking that dependency count:

Before you folks go doing something you might later regret, it would be great if there was some objective criteria of how many dependencies are too many. Crates that depend on other smaller crates (mainly smol-rs ones in case of zbus unless tokio is enabled) instead of re-implementing everything internally, also bring some advantages, such as faster parallel build, significantly reduced hot build time, lower binary size in general (depends on how (un)lucky you are), and most importantly IMO, just being a good Open Source citizen.

So just looking at the number of deps alone is not a good idea. A better criteria would be the total binary size of all the deps combined.

1. Put pressure on the zbus maintainers to shrink their dependency count. But I don't want to just complain, particularly about something we got for free.

I appreciate that you don't want to complain but instead of putting pressure, maybe another option would be to work with zbus maintainers (currently it's just me, working on it in my spare time) to address the issues at hand?

2. Use a different Rust D-Bus implementation, like the [dbus](https://crates.io/crates/dbus) crate, which uses the libdbus C library. I don't remember all the reasons why the primary author of the AccessKit Unix adapter decided to go with zbus instead, though we discussed it at the time, and I obviously approved the decision. But requiring a C library instead of being a pure-Rust implementation is obviously a downside of this option.

If dbus-rs was a great API, I wouldn't have gone down the rabbit hole of writing zbus. If that works better for you, by all means go for it! Just keep in mind that portability wouldn't be as easy then.

3. Write an alternative pure-Rust D-Bus implementation that's specifically designed to be small-footprint and low on dependencies. I don't have time to do this now. I might have time to do it later if someone can pay for it.

Let me tell you a bit of a story. After I gave presentation on zbus (before the first release) in late 2019, a lot of people got this idea that D-Bus can't be that hard somehow (even though I said the opposite) and many D-Bus crates popped up. Many of them didn't go anywhere at all but some of them got to some point where they were just good enough for the very specific needs of the author. However, slowly they all just died out. Never got to the point of being generally useful.

So if that's the route you want to take, that's entirely up to you of course but keep in mind, it's going to be a lot of work. You can reduce the work immensely if you use zvariant but I believe if the output of cargo bloat is to be trusted, the generics there are a significant part of the binary size.

The AccessKit Unix adapter, and again zbus in particular, also has a noticeable effect on binary size. I measured about 1 MB when optimizing for size.

That's w/o optimizations, isn't it? With some optimizations, it can be reduced by half.

The impact on dependency count and binary size is much less dramatic on other platforms.

Have you found a more reliable method that cargo bloat to measure btw? cargo bloat itself says to take its output with a grain of salt.

[mwcampbell]

another option would be to work with zbus maintainers (currently it's just me, working on it in my spare time) to address the issues at hand?

@zeenix You're right, that's a better way for me to approach this. And I appreciate all the work you've done on zbus in your spare time.

I want to take a closer look at the state of dbus-rs though. AccessKit doesn't have to statically link the platforms' IPC mechanisms on Windows or macOS. So I think the only way to achieve a comparable (lack of) bloat for the free desktops is to use the D-Bus C library, as we use the equivalent C or Objective-C APIs on Windows or macOS. The portability complications that come with using a C library are definitely something to consider, though. What would the Bevy project prefer?

[zeenix]

AccessKit doesn't have to statically link the platforms' IPC mechanisms on Windows or macOS. So I think the only way to achieve a comparable (lack of) bloat for the free desktops is to use the D-Bus C library

Fair enough but if avoiding bloat through dynamically linking to libs is what you're aiming for, you may want to reconsider using Cargo at all tbh.

[ahicks92]

Avoiding bloat as an app developer with cargo can be difficult, but avoiding bloat as a lib developer is entirely doable. The difference Matt is alluding to however is that on OSX, Windows, iOS and I believe also Android, the accessibility mechanisms are IPC built into the OS fundamentally. Linux is the weird outlier since it doesn't even necessarily have a desktop environment, "native" widgets are only a thing by convention, and accessibility isn't really a super high priority beyond specific circles.

I personally think bevy should opt to not care and turn it on by default for Linux, but I am blind so I guess I'm biased, and starting optional at least gets it out the door. I think the more important point is that no one is going to turn accessibility on unless someone figures out how to get as far as the devs and also the app is still maintained the first time someone with insert-disability needs to use it. Since this is off at the "we didn't compile it in" level, there's nothing to be done for any app that doesn't fulfill the full set of conditions. A megabyte or so increased binary size isn't great but to me it's a lot better than subsets of users who could otherwise have used a thing without intervention needing to advocate on a per-app basis.

[mwcampbell]

@cart (and the rest of the Bevy core team): How much do we need to reduce the binary footprint of the AccessKit Unix adapter before it can be enabled by default, or ideally not feature-gated at all? If the answer is that the Unix adapter shouldn't be much larger than the Windows or macOS adapter, then I think the only way we can achieve that is by using C libraries (e.g. libdbus or GLib) where we currently use pure Rust (zbus). Which is the lesser evil, increased binary size or more C dependencies? And for the added C dependencies to meaningfully reduce binary size, they have to be installed system-wide.

[alice-i-cecile]

For me, "added C dependencies" is much much worse. My personal feeling is that "as reduced as reasonably possible" is the bar here: the goal is to reduce footprint where there's low hanging fruit.

[cart]

Just to make one thing very clear as I think some people have missed aspects of the discussion above due to GitHub pull request UI being really good at hiding discussions:

My end criteria for this effort is for accessible UI to be enabled by default on every platform. The only question at this point is how. The current "feature flag on linux" is a short term middle ground solution while we sort out the best way to handle this situation.

Before you folks go doing something you might later regret, it would be great if there was some objective criteria of how many dependencies are too many. Crates that depend on other smaller crates (mainly smol-rs ones in case of zbus unless tokio is enabled) instead of re-implementing everything internally, also bring some advantages, such as faster parallel build, significantly reduced hot build time, lower binary size in general (depends on how (un)lucky you are), and most importantly IMO, just being a good Open Source citizen.

I've already outlined my stance on this above and touched on the same pros and cons you discussed here. I can't really be more specific than "60 new deps is almost certainly way too much" and "17 is closer to being an acceptable number" without really diving into the details. I agree that dep count is a complicated topic with many dimensions to it. I'll call out that with the alternative being discussed (binding to a c lib), binary size and build time would both go way down. So I don't see "increased parallelism due to high dep count" as a particularly good selling point in this context when the alternative is "4 new tiny deps".

I'll also note that we do value being a Good Open Source Citizen in Bevy land. We aren't dependency averse to the extent of some other projects in the space (such as Macroquad ... but I'll note that they have signficantly better build times and binary sizes than we do because of their rigorous dep-aversion / lack-of-ecosystem-participation). We take targeted ecosystem dependencies in the interest of sharing effort / being good ecosystem players. But we strike a balance with keeping our developer UX in check. See my stance linked above on this. If we take a laissez-faire attitude to deps, this will bite us in a multitude of ways. To summarize again: binary size (in many cases), compile times (in many cases), increased chance of "illegal" semver breakage, increased chance of mismatched dep versions, increased threat surface, decreased user perception of "slimness" ... for better or worse people will look at dep counts when forming their opinions, and increased licensing compliance burden / aggregate license file size for deployed apps.

I appreciate that you don't want to complain but instead of putting pressure, maybe another option would be to work with zbus maintainers (currently it's just me, working on it in my spare time) to address the issues at hand?

I'm very open to this! Some thoughts:

• Reworking zbus to cut down on deps would likely be a larger / longer term project. People are clearly itching to get this enabled by default asap, so we might need to make a different call in the short term. But I also don't know off the top of my head how the "slim down zlib" work would compare to porting accesskit to a c dbus lib.
• Reworking zbus will yield "unclear wins" at this point. I can't promise that even after finishing a rework effort we would take the dep.
• Note that Bevy has a relatively unique (and strict) set of requirements. If we don't choose to use zbus here, that doesn't mean I wouldn't endorse the project generally or use it in my other projects.

Just keep in mind that portability wouldn't be as easy then.

Linking to c libs isn't inherently bad for portability, it just can be bad. We already link to a huge number of them via deps like wgpu, winit, cpal, gilrs, etc. I think this really depends on the specifics of library availablility on systems. I don't have an answer to this problem space.

I'll be honest, if its not clear yet: I'm pretty biased toward pursuing the c lib linking route here (within the context of Bevy specifically).

Alternatively, if anyone wants to do a breakdown of present or future zlib impls that demonstrate that the "dep cost" (in the dimensions I listed above) is competitive with whatever c-lib-linking-impl we would use, I'm on board. Make your case with numbers and I'll listen.

I'm also curious to see how hard it would be to make accesskit support either zbus or dbus-rs / some other clib option (via cargo config). That would make comparisons easier and it would make it easier to migrate whenever we're happy with tradeoffs. Before making any final decision we need to compare the actual "dep-related concern" numbers and gather data on system compatibility.

I personally think bevy should opt to not care and turn it on by default for Linux, but I am blind so I guess I'm biased, and starting optional at least gets it out the door.

This is certainly a hard call, but from my perspective if we enabled the current impl by default right now we would:

1. Immediately compromise Bevy in the dimensions discussed above. Every user of Bevy would "pay the price"
2. Remove pretty much all incentive from the parties involved here to "do this in the way that I think Bevy needs it to be done".

I don't think that would be the correct "optimal solve" for this situation. I'm confident that if we continue to hold our requirement bar reasonably high, that we can meet those requirements in relatively short order. I really don't want to be the "bad guy" here, but I consider myself responsible to all parties in the Bevy community, not just the ones in this thread currently. I'm doing that in the best way I know how. Please let me know if you think I'm not doing that job effectively.

[zeenix]

To summarize again: binary size (in many cases), compile times (in many cases), increased chance of "illegal" semver breakage, increased chance of mismatched dep versions, increased threat surface, decreased user perception of "slimness" ... for better or worse people will look at dep counts when forming their opinions, and increased licensing compliance burden / aggregate license file size for deployed apps.

I can't stop people in general making the mistake of shallow assessments but if we want to make a fair assessment, we need to pay attention to specific details. E.g we needed a broadcast channel API in zbus. I could have just implemented it in zbus itself and that would have looked like a win from your perspective as it would have meant one less dependency. Instead I decided to revive an unfinished smol-rs crate so others can use it too. Another example of the same is ordered-stream crate. We didn't really need to split it into another crate.

Many of ours deps are part of the same project, which are split into multiple smaller crates so people can only link the API they need. This means (among other things) there is no increased license compliance burden as all the crates under the same project are under the same license and no increased risk of MSRV bumps etc.

BTW, I noticed that you also seem to like splitting your project into multiple smaller crates rather than keeping a monolith? People can raise the same point against bevy use (directly or indirectly) if they decide based primarily on number of dependencies added.

I'll call out that with the alternative being discussed (binding to a c lib), binary size and build time would both go way down. So I don't see "increased parallelism due to high dep count" as a particularly good selling point in this context when the alternative is "4 new tiny deps".

I wasn't saying that in the context of zbus vs dbus-rs, that would be apple and oranges in this case. There are other reasons (that I mentioned) to prefer zbus over dbus-rs.

My point was that if zbus had fewer deps by 1. implementing things internally and 2. depending on monolithic crates, we'd be seen as heroes to people who just look at the number of deps but it would have meant (among other things), decreased build parallelism.

Just keep in mind that portability wouldn't be as easy then.

Linking to c libs isn't inherently bad for portability, it just can be bad.

I did not say that it's inherently bad. All I can tell you is that I've had multiple people come to me about being unable to cross build their zbus-using code and then it turns out it was because they forgot to remove dbus-rs from their Cargo.toml after porting to zbus.

Don't know how much you know about D-Bus at all but the C library in question here is notoriously bad and undermaintained. I don't know any C app/lib that actually uses it. They all use gio (which is what inspired zbus coincidentally).

---

Anyway. I think I've put enough of my energy here. It's your project so leave it in your capable hands to make the decision. I provided all the information I could provide so my job here is done. I will now unsubscribe from this but if you have any zbus (or D-Bus) questions, you're more than welcome to contact me either through our our matrix channel or the issue tracker but please don't @ me so I don't get re-subscribed. Thanks. 🙏

[mwcampbell]

Given the state of the libdbus C library, which was also made clear to me in a chat in the GNOME Accessibility matrix room last weekend, I'm ruling out that option for AccessKit.

According to my measurements, the executable footprint of zbus increased sharply with zbus 2, when the implementation was converted from blocking to async. Of course, this change also added several new dependencies.

So I'm thinking about forking zbus 1 to start a new project with the explicit goal of keeping executable size and dependency count low. Of course, this is going to lead to some duplicated effort to reimplement bug fixes and possibly some features that were already implemented in zbus 2.x and 3.x. But it may be the quickest way out of the current situation.

[Be-ing]

I'm thinking about forking zbus 1 to start a new project with the explicit goal of keeping executable size and dependency count low.

This would backfire and have the opposite result for many applications which would still need zbus for other purposes.

[mwcampbell]

There's one thing Zeeshan Ali said about the libdbus C library (used by the dbus crate) that's not entirely accurate. It is in fact used by some applications. In particular, the Orca screen reader uses it (via the libatspi library), and all GTK 3 applications use it when accessibility is enabled (again via libatspi, and atk-bridge). While the GNOME accessibility stack doesn't exactly have a reputation for robustness, I don't know if any actual GNOME accessibility bugs or general instability are due to problems with libdbus.

So I'm reconsidering the option of using libdbus via the dbus crate.

[mwcampbell]

Another complication with the option to use libdbus via the dbus crate: The D-Bus reference implementation, including libdbus, is dual-licensed under GPL 2 and Academic Free License (AFL) 2.1. My understanding is that AFL 2.1 is a permissive license similar to the Apache license, but still, it's another license. And this info isn't currently reflected in the metadata of the dbus or libdbus-sys crate.