gio: Convenience macro for implementing DBus interfaces

[tautropfli]

(Veeeery WIP)

Edit: I have started working on a new version with the shape suggested in the «Rust ❤️ GNOME» Matrix room. For reference, the old version (the one currently described in this PR's description) can be found in the dbus-interface-derive-v2 branch.

My goal is to have a macro very similar to what zbus has with their #[zbus::interface] macro.
There's no need to specify an XML as the DBusInterfaceInfo is also generated.

I originally wanted the macro to implement DBusInterfaceSkeleton but this interface has so many footguns that I decided to go with my own trait DBusExportableInterface for now.
It essentially exposes all the parts that are usually passed to register_object.

The macro implements the DBusInterfaceSkeleton interface.

#[derive(Default, gio::DBusInterfaceSkeleton)]
#[dbus_interface(name = "com.github.gtk_rs.examples.HelloWorld")]
pub struct HelloWorldSkeleton {
    // ...
}

#[gio::dbus_methods]
impl HelloWorldSkeleton {
    #[deprecated]
    fn hello(&self, name: String) -> String {
        let greet = format!("Hello {name}!");
        println!("{greet}");
        greet
    }

    #[dbus(out_args("name", "effective_delay"))]
    async fn slow_hello(
        &self,
        #[dbus(connection)] connection: gio::DBusConnection,
        #[dbus(invocation)] invocation: gio::DBusMethodInvocation,
        name: String,
        delay: u32,
    ) -> Result<(String, f64), glib::Error> {
        if delay > 4 {
            return Err(glib::Error::new(
                gio::DBusError::InvalidArgs,
                "delay must not be greater than 4 seconds",
            ));
        }

        let instant = Instant::now();
        glib::timeout_future(Duration::from_secs(delay as u64)).await;
        let greet = format!("Hello {name} after {delay} seconds!");
        println!("{greet}");
        Ok((greet, instant.elapsed().as_secs_f64()))
    }

    #[allow(clippy::manual_async_fn)]
    fn goodbye(&self) -> impl Future<Output = ()> {
        async {
            if let Some(app) = self.application.borrow().upgrade() {
                app.quit();
            }
        }
    }
}

Todo

• Properties
• Signals
• [ ] Convenience for registering an object that implements DBusExportableInterface Not needed since we implement DBusInterfaceSkeleton.
• Cleanup
• Tests
• Documentation

[bugaevc]

Why do you need a OnceLock for this, it's all constant data that should reside in .rodata?

[tautropfli]

method return types are sadly not known at macro evaluation time, see my other reply

[bugaevc]

There should be a way to specify this. (See this patch for Vala.)

[bugaevc]

I don't think I understand this. Why do we only know that at runtime?

[tautropfli]

Proc macros don't have access to type information, only syntax. So we can only recognize tuples that are directly specified as return type using tuple syntax but not type aliases for tuples or structs that marshal to tuple variants.

[tautropfli]

We could use const evaluation here, but that would require everything related to the StaticVariantType to be marked const.

[bugaevc]

Proc macros don't have access to type information, only syntax.

That looks very unfortunate...

So we can only recognize tuples that are directly specified as return type using tuple syntax but not type aliases for tuples or structs that marshal to tuple variants.

We should require people to always use plain tuples without aliases then (i.e. emit a compile-time error if they don't). Lest we fall into the same trap as zbus.

[bugaevc]

Alternatively, yes, using traits for this would make sense. Can't we require the return type to impl some trait (be it StaticVariantType or not) that has a const VARIANT_TYPE: &'static str?

[tautropfli]

So we can only recognize tuples that are directly specified as return type using tuple syntax but not type aliases for tuples or structs that marshal to tuple variants.

We should require people to always use plain tuples without aliases then

I should have specified a bit better, my comment was about what information we have at macro evaluation time. At runtime (through StaticVariantType) we do know if a type is a tuple. That's why I currently generate code that puts together the out_args at runtime rather than at macro expansion time.

So right now there is no disconnect between introspection and return value.

Making a const version of StaticVariantType is probably a whole project onto itself 😅 I would rather not have to parse variant strings.