Document what macro dbus_proxy derives for trait
Due to both rust-analyser and CLion not coping very well (or at all) with code completion for functions and structs derived via attribute macro there needs to be additional help in the dbus_proxy doc comments.
For example:
#[dbus_proxy(
interface = "org.test.SomeIface",
default_service = "org.test.SomeService",
default_path = "/org/test/SomeObject"
)]
trait SomeIface {
fn do_this(&self, with: &str, some: u32, arg: &Value) -> Result<bool>;
#[dbus_proxy(property)]
fn a_property(&self) -> fdo::Result<String>;
#[dbus_proxy(property)]
fn set_a_property(&self, a_property: &str) -> fdo::Result<()>;
#[dbus_proxy(signal)]
fn some_signal(&self, arg1: &str, arg2: u32) -> fdo::Result<()>;
};
it wasn't immediately obvious that SomeIface
is derived to SomeIfaceProxy
. A line or two explicitly stating that this happens would be more helpful than a code example as it would give concrete language about it. Something like the following maybe?
"The macro must be applied on a trait T. A matching impl T will provide the proxy with the name of <trait_name>Proxy
. The proxy instance can be created with the associated new() or new_for() methods. The former doesn't take any argument and uses the default service name and path. The later allows you to specify both."
Additionally the same is true for signals where the following may be okay?
"signal - declare a signal just like a D-Bus method. The macro will provide a method to register and deregister a handler for the signal with the names of connect_<signal_name>
and disconnect_<signal_name>
, whose signature must match that of the signature declaration."
Although that part was reasonably clear in the example code it may still be of benefit to use explicit language to state what happens.
Lastly it might be of benefit to state "Attribute macro for defining a D-Bus proxy. All Proxy methods are available on the derived proxy."