Macro for generating signals() and emit_/connect_ functions for subclass

[ids1024]

When defining a GObject type in Rust, it is necessary to define a ObjectImpl::signals() function, and useful to define the emit_ and connect_ functions like the ones generated by gir.

Considering a few things, this seems like a reasonable API for it, which I think would work:

glib::wrapper! {
    signals {
        fn signal_without_params();
        fn signal_with_params(i32, String);
        fn signal_with_params_and_return(i32, String) -> bool;       
    }
    pub struct FooObject(ObjectSubclass<FooObjectInner>);
}

I guess it would be necessary for the caller to define ObjectImpl::signals() to call a function generated by the macro. Kind of similar to the boilerplate required with composite templates. I can't think of a way to avoid a slight complication like this.

Alternately to making this part of glib::wrapper!, it could be a separate macro, or an attribute macro on something. Given glib::wrapper! is necessary, it seems cleaner to add it here. It could also generate the connect_/emit_ functions for types other than ObjectSubclass (code currently generated in gir).

Properties should be handled in a similar way, but that's more complicated since it would be good for it to automatically store a value if there is no custom getter/setter, while also supporting custom getters and setters. And then there's a need to define nick, blurb, and default value.

[ids1024]

Kind of similar to the boilerplate required with composite templates. I can't think of a way to avoid a slight complication like this.

Or maybe that's not a problem. signals() could be a method of ObjectSubclassIs (the trait implemented when glib::wrapper! is used with ObjectSubclass<...>).

ObjectImpl::signals() could have a default implementation calling Self::Type::signals() (or a different function name). Or alternately it could be removed (making this a breaking change) if a manual implementation of signals isn't really useful.

[jf2048]

I have implemented a (very WIP) version of this in another repo: gobject-impl

But let's wait until we figure out what is going on with #546 first before I try to port it upstream

[pjungkamp]

I think the macro should take inspiration from the existing gtk4::template_callbacks and glib::properties macros to keep the developer experience consistent.

From gtk4::template_callbacks:

• use a proc-macro on an impl block and generate code for all functions tagged with #[signal(...)]

From glib::Properties:

• the macro should be defined for the ObjectSubclassImpl type (e.g. FooObjectInner above)
• take a wrapper_type = ... parameter, that is used to generate the emit and connect functions
• generate a function on the ObjectSubclassImpl type that returns the list of signals, similar to derived_properties
• provide simple meta attributed for setting a well-typed accumulator function

---

I was thinking of something like this.

glib::wrapper! {
    pub struct FooObject(ObjectSubclass<imp::FooObject>);
}

mod imp {
    #[derive(Default)]
    struct FooObject;
    
    #[glib::object_subclass]
    impl ObjectSubclass for FooObject {
        const NAME: &str = "FooObject";
        type Type = super::FooObject;
    }

    #[glib::signals(wrapper_type = super::FooObject)]
    impl FooObject {
        #[signal(run_first)]
        fn signal_without_params(&self) {
        }
        
        #[signal]
        fn signal_with_params(&self, a: i32, b: String) {
            // class handler
        }
        
        #[signal(accumulator = |_hint, acc: &mut bool, val: &bool| acc && value)]
        fn signal_with_params_and_return(&self, a: i32, b: String) -> bool {} 
    }
    
    impl ObjectImpl for FooObject {
        fn signals() -> &'static [glib::subclass::Signal] {
            Self::generated_signals()
        }
    }
}

This should then generate something like:

mod imp {
    // ...

    impl FooObject {
        // all the #[signal] functions
        
        fn generated_signals() -> &'static [glib::subclass::Signal] {
            static SIGNALS: std::sync::OnceLock<[glib::subclass::Signal; 3 /* statically known count */]> = std::sync::OnceLock::new();
            SIGNALS.get_or_init(|| [
                glib::subclass::Signal::builder("signal-without-params")
                    .run_first()
                    .class_handler(|_token, params| {
                        let wrapper: super::FooObject = params[0].get().unwrap();
                        wrapper.imp().signal_without_params();
                        None
                    })
                    .build(),
                    ...
            ])
        }
    }

    // ...
}

---

I don't quite understand the need for the SignalClassHandlerToken in the arguments to the class handler. As far as I understand this token should only be needed in an overridden class handler. Is it even possible to override a class handler from a parent in the array returned from ObjectImpl::signals?

[sdroege]

Is it even possible to override a class handler from a parent in the array returned from ObjectImpl::signals?

No, you'd call class.override_signal_class_handler() from inside ObjectSubclass::class_init().

I think you're right that the token is only needed for the closure of that function, not for the main class handler. This should probably also get a test.

Let's fix that :)

[sdroege]

See #1575