Add gclosure macro

[jf2048]

Fixes #19, probably also good enough for #23

I tried to copy the syntax of clone! as much as I could. This should be a convenient improvement on connect_object since this can take weak references on multiple objects in one call.

[sdroege]

Thanks, this looks really promising. I'll review it in detail later.

probably also good enough for #23

If you pass the object into the closure as a weak reference then for normal usage yes. However GtkBuilder signal handlers can also use this flag, and then connection to the signal must happen slightly differently (I forgot the details).

[sdroege]

probably also good enough for #23

If you pass the object into the closure as a weak reference then for normal usage yes. However GtkBuilder signal handlers can also use this flag, and then connection to the signal must happen slightly differently (I forgot the details).

Which you implement differently in the GtkBuilder case in the other PR, so that's indeed covered then :)

[jf2048]

Which you implement differently in the GtkBuilder case in the other PR, so that's indeed covered then :)

Indeed, I thought I would use this macro there initially but it turned out to not be very practical to do it that way, since BuilderRustScope needs to take callbacks and only creates the closure objects on demand.

[A6GibKm]

Is there a reason it is called glib::gclosure rather than glib::closure? In my opinion it goes against how namespaces work in Rust.

[jf2048]

It was closure! first, then I named it gclosure! because I thought maybe it made sense because the macro returns a Closure, not a rust native type. It probably should be changed back to closure! though now that you mention it.

[sdroege]

It was closure! first, then I named it gclosure! because I thought maybe it made sense because the macro returns a Closure, not a rust native type. It probably should be changed back to closure! though now that you mention it.

See also #341 (comment) . My reasoning would've been the same for calling this one gclosure!, but OTOH it's glib::Closure and not glib:GClosure. I have no strong opinion here, there are arguments for both.

@bilelmoussaoui @GuillaumeGomez ?

[sdroege]

Let's keep this one as gclosure! and worry about it in general in #343