Add glib::signals! macro

[PJungkamp]

This is my initial implementation of the ideas from #214 (comment) and currently only creates an implementation of a DerivedObjectSignals trait modeled after the DerivedObjectProperties used by the Properties macro. It needs some cleanup (a couple of unused elements/fields/imports) and it's also missing the generator for the connect_ and emit_ functions.

The basics seem to work. But I'm now wondering how exactly signal class handlers work. Is the class handler function invoked if none of run_first, run_last or run_cleanup are specified?

[bilelmoussaoui]

It would be nice to add a derived_signals macro as well, not much work and would make the migration to use the future signals macro more appealing

[bilelmoussaoui]

missing the generator for the connect_ and emit_ functions.

For the connect_ functions, you would have to use ObjectExt::connect_closure and create a glib::closure!, pass the params the signal function signature got to the created closure. A local variant of the connect_ function should also be generated using glib::closure_local!

Something that I haven't seen any note about is the signal details, not sure how to handle it.

[sdroege]

I wonder if it would be possible to make

Suggested change

	fn awarded(&self) {}
	fn awarded(&self);

and that means that the signal has no class handler, and

Suggested change

	fn awarded(&self) {}
	fn awarded(&self) { println!("stuff"); }

which means that it has a class handler with the body of the function.

In the first case, the macro would have to remove the whole function after expansion.

[felinira]

I almost never use class handlers in my signals so I would appreciate something like that too.

[PJungkamp]

A function without a block isn't valid rust syntax outside of an extern block. I don't want to add some invalid Syntax that would be removed by the macro.

It's also way more complicated to parse this. I would have to write a custom parser based on syn::ItemImpl that accepts these "invalid" functions. And it confuses other parsing code for other macros or rustfmt.

I can add and parse a toplevel pseudo-macro, meaning something like this would be ok:

#[glib::signals(wrapper_type = super::FooObject)]
impl FooObject {
    signals! {
        fn awarded() -> i32;
    }
}

This pseudo-macro is valid Rust Syntax and should work with rustfmt and other macros.

[bilelmoussaoui]

Maybe instead of using an impl Object, the usage could be trait ObjectSignals making it possible to provide a default impl?

[PJungkamp]

Default implementations can only use methods provided by the trait's required subtraits and itself.

The class handler implementations would have to reside in an impl ObjectSignals for FooObject block.

I don't really see how I'd map a trait to a definition of signals, as I don't want the macro to modify the trait in ways that make it hard for a developer to understand what the trait will actually look like.

The problem I see is that a semicolon instead of a block in a trait definition means that you have to provide the class handler in your implementation of that trait, while you want it to mean that there is no class handler.

[bilelmoussaoui]

The trait itself wouldn't be used. You can then impl T for SomeObject and forward the calls when the trait has an impl, no?

Anyways, zbus is using something similar for it zbus::proxy! macro.

[sdroege]

For the connect_ functions, you would have to use ObjectExt::connect_closure and create a glib::closure!, pass the params the signal function signature got to the created closure. A local variant of the connect_ function should also be generated using glib::closure_local!

This should only be done for non-Sync objects though. I think this will need to be configurable, can't really auto-detect that.

[sdroege]

But I'm now wondering how exactly signal class handlers work. Is the class handler function invoked if none of run_first, run_last or run_cleanup are specified?

It's not called at all AFAICS (see signal_emit_unlocked_R() in glib/gobject/gsignal.c).