Bump 'ashpd' version to '0.10.2'

[bal-e]

I've been trying out Slint for a bit, and I think it's really neat! One of my concerns is the size of the dependency tree, even for really minimal builds (e.g. disabling accessibility and only using the winit backend and femtovg renderer gives ~500 transitive dependencies).

'ashpd' version 0.9 relies on 'async-io' by default, which pulls in a lot of extra crates. 'ashpd' 0.10 switches to 'tokio' by default. I hope this cuts down the size of Slint's dependency tree. From what I can tell, everything still builds just fine. I haven't been able to run tests because rustc hits OOM when trying to compile them.

[CLAassistant]

All committers have signed the CLA.

[tronical]

Thanks for the PR and initiative!

The main reason why I opted for the older version of Ashpd is so that zbus/zvariant aren’t duplicated dependencies via AccessKit (atspi-common).

I’d like to upgrade when AccessKit upgrades.

In terms of async runtime, I’d prefer of AccessKit and ashpd use zbus with async-io instead of tokio, because the former has just a single I/o thread - that seems lighter.

That said, there is another way to reduce dependencies: replacing ashpd with zbus directly to watch the color scheme dbus property.

What do you think?

[bal-e]

Thanks for the quick response! I'm glad that we agree this is an issue.

I didn't notice AccessKit needs zbus too; I completely understand waiting until it upgrades (is there a PR for that, by the way? I might make one if not).

While I agree that async-io would be lighter than tokio in isolation, users of Slint also need to do I/O often (perhaps not in the no-std case -- but then async-io wouldn't work either). If an application is doing two or more async I/O operations at the same time, Tokio is a better choice. I think tokio's popularity is well-established, and I expect Slint's users (for desktop applications) to rely on it quite often. If you're not comfortable with that assumption, perhaps a tokio / async-io feature flag on the slint crate is warranted.

I like your idea of skipping ashpd and just using zbus directly. I haven't peeked around the code much, but given the breadth of ashpd's API, I imagine a single module is relatively tiny. I can make a new PR which tries that out. Still, the above discussion w.r.t tokio is important.

[tronical]

Thanks for the quick response! I'm glad that we agree this is an issue.

I didn't notice AccessKit needs zbus too; I completely understand waiting until it upgrades (is there a PR for that, by the way? I might make one if not).

Once a new access kit version is released that depends on a newer zbus, then we should upgrade. The current version of accesskit_unix uses zbus 4. I suspect a future version may upgrade.

While I agree that async-io would be lighter than tokio in isolation, users of Slint also need to do I/O often (perhaps not in the no-std case -- but then async-io wouldn't work either). If an application is doing two or more async I/O operations at the same time, Tokio is a better choice. I think tokio's popularity is well-established, and I expect Slint's users (for desktop applications) to rely on it quite often. If you're not comfortable with that assumption, perhaps a tokio / async-io feature flag on the slint crate is warranted.

I think Slint should not impose a run-time choice on their users and minimise dependencies, and if possible the internal concerns (how the winit backend talks to dbus services) should be separated from the application. As such, I think async-io is a great choice for Slint implementation details. If the application wants to use async-io as well, that's fine - they can share the thread. If the application wants to use tokio, then it's free to do that and I think it's an acceptable situation that Slint has one background thread running. Tokio and async-io can co-exist in the same process, fortunately.

I like your idea of skipping ashpd and just using zbus directly. I haven't peeked around the code much, but given the breadth of ashpd's API, I imagine a single module is relatively tiny. I can make a new PR which tries that out. Still, the above discussion w.r.t tokio is important.

It would be awesome if you have time to explore using zbus directly. It seems to me that the color scheme is a u32 and with a zbus object proxy listening to the SettingChanged signal would likely do the trick. I think ashpd basically forwards from that.