Yah, that is very true regarding dbus. 
I have not made a program that publishes events, but this seems to be per-program from what I’ve seen when I was debugging the interface.
The only reference I could find which supports this is at https://freedesktop.org/wiki/IntroductionToDBus/
Plan to update this thread with a more thorough breakdown when I wrap up the project but I just wanted to mention that in order to get the functionality out of dbus that I really wanted I had to break down and use Rustler to wrap dbus-rs bindings. The interaction can then be handled with busctl from scripts or from within the app using the dbus-rs calls. I’m sure there are other ways but this is the only workable solution I could find.
To anyone interested, I wanted to use the zbus crate instead of dbus-rs because the documentation on that crate is so good, but zbus is async first, so much that even the blocking API requires use of async. Async functions with Rustler were a layer of complexity beyond my current capacity.
I haven’t touched Rust in several months but if memory serves there are two ways:
async fn do_async_stuff() -> usize {
return 7;
}
fn main() {
let future = do_async_stuff();
futures::executor::block_on(future);
}
#[tokio::main] macro and just put the 3-4 lines of boilerplate code in yourself, see here for info: main in tokio - Rust – I have copied the runtime initialization code from there) then you can just use it like this:async fn do_async_stuff() -> usize {
return 7;
}
fn main() {
let mut rt = tokio::runtime::Builder::new_multi_thread()
.enable_all()
.build()
.unwrap();
let future = do_async_stuff();
rt.block_on(future);
}
Rust async allows you to introduce those crossing points between async and sync code.
Thanks. The issue was around implementing Encoder trait or something like that. Not really the async logic itself. I just want sure how to implement for a Future.
Thank you for the sample code, it was helpful to get started! Trying this out, I would lean towards using a library for anything non-trivial. First impressions from my armchair are that D-Bus has a non-standard data and type wire format that I would not like to learn, the protocol can be used to publish a service, and processes can notify one another. The spec is a bit big, for example defining its own authentication on top of SASL, and it seems that none of the BEAM libraries implement the whole spec yet.
For now though, I have similarly limited needs as others here and I can hide the ad-hoc bits in a single-purpose module. I’m trying to detect and integrate with a local music player, so I wanted the session pointed to by the logged-in user’s DBUS_SESSION_BUS_ADDRESS environment variable, which is passed through to the System.cmd transparently. This makes the send method simpler,
def send(dest, object_name, action, message \\ nil) do
{output, 0} =
System.cmd(
"dbus-send",
[
"--session",
"--print-reply=literal",
"--dest=#{dest}",
object_name,
action
] ++ if(message, do: [message], else: [])
)
output
end
My usage can ignore the custom data serialization for now,
def mediaplayer2_available?() do
send(
"org.freedesktop.DBus",
"/org/freedesktop/DBus",
"org.freedesktop.DBus.ListNames"
)
|> String.match?(~r/MediaPlayer2/)
end