Signal connection wth Builder #359
Conversation
This should be less of a problem once I finally finished #31 . Then you can treat all the types the same without the distinction of nullable/non-nullable types like now. |
| match values[#index].get_some() { | ||
| Ok(value) => value, | ||
| Err(error) => { | ||
| glib::g_critical!("builder handler", "Handler {} expects an argument of type {} but received `{:?}`: {}.", #handler_name, stringify!(#arg_type), values[#index], error); |
There was a problem hiding this comment.
This should be a panic in one way or another. Returning None can easily cause memory safety issues in the C code calling this signal handler.
gtk3-macros/src/builder_handlers.rs
Outdated
| quote_spanned! { info.sig.span() => | ||
| #signal => Some({ | ||
| #[allow(unused_variables)] | ||
| Box::new(glib::clone!(@weak self as this => move |values: &[glib::Value]| { |
There was a problem hiding this comment.
I think instead of having to work with a struct Foo(Widget) kind of type, it would make more sense to integrate this with subclassing and especially composite templates.
That way you could have the macro on the impl struct, and use the ObjectSubclass::from_instance() / ::get_instance() functions to get to a widget and back.
andy128k
force-pushed
the
issue_128_builder_handlers
branch
from
0355be8 to
2593a8c
Compare
Addresses #128
Implementation is similar to #266
This looks not very useful.
FromValueis not implemented for aglib::Object(andgtk::Widget), so handler's arguments are limited to primitive types.